Re: why postgresql over other RDBMS
От | Erik Jones |
---|---|
Тема | Re: why postgresql over other RDBMS |
Дата | |
Msg-id | D7C2606C-357E-45DA-A6A0-4F5DD3768BBD@myemma.com обсуждение исходный текст |
Ответ на | Re: why postgresql over other RDBMS (Chris Browne <cbbrowne@acm.org>) |
Список | pgsql-general |
On May 24, 2007, at 5:21 PM, Chris Browne wrote: > agentm@themactionfaction.com ("A.M.") writes: >> On May 24, 2007, at 14:29 , Wiebe Cazemier wrote: >> >>> On Thursday 24 May 2007 17:30, Alexander Staubo wrote: >>> >>>> [2] Nobody else has this, I believe, except possibly Ingres and >>>> NonStop SQL. This means you can do a "begin transaction", then >>>> issue >>>> "create table", "alter table", etc. ad nauseum, and in the mean >>>> time >>>> concurrent transactions will just work. Beautiful for atomically >>>> upgrading a production server. Oracle, of course, commits after >>>> each >>>> DDL statements. >>> >>> If this is such a rare feature, I'm very glad we chose postgresql. >>> I use it all >>> the time, and wouldn't know what to do without it. We circumvented >>> Ruby on >>> Rails' migrations, and just implemented them in SQL. Writing >>> migrations is a >>> breeze this way, and you don't have to hassle with atomicity, or >>> the pain when >>> you discover the migration doesn't work on the production server. >> >> Indeed. Wouldn't it be a cool feature to persists transaction states >> across connections so that a new connection could get access to a >> sub- >> transaction state? That way, you could make your schema changes and >> test them with any number of test clients (which designate the state >> to connect with) and then you would commit when everything works. >> >> Unfortunately, the postgresql architecture wouldn't lend itself well >> to this. Still, it seems like a basic extension of the notion of sub- >> transactions. > > Jan Wieck had a proposal to a similar effect, namely to give some way > to get one connection to duplicate the state of another one. > > This would permit doing a neat parallel decomposition of pg_dump: you > could do a 4-way parallelization of it that would function something > like the following: > > - connection 1 opens, establishes the usual serialized mode > transaction > > - connection 1 dumps the table metadata into one or more files in a > specified directory > > - then it forks 3 more connections, and seeds them with the same > serialized mode state > > - it then goes thru and can dump 4 tables concurrently at a time, > one apiece to a file in the directory. > > This could considerably improve speed of dumps, possibly of restores, > too. > > Note that this isn't related to subtransactions... Interesting. That's actually pretty close to the reindexing strategy/ script that I use and I've been planning on extending it to a vacuum strategy. So, I will add my support into someone building this kind of support into pg_dump/restore. Erik Jones Software Developer | Emma® erik@myemma.com 800.595.4401 or 615.292.5888 615.292.0777 (fax) Emma helps organizations everywhere communicate & market in style. Visit us online at http://www.myemma.com
В списке pgsql-general по дате отправления: