Re: why postgresql over other RDBMS

agentm(at)themactionfaction(dot)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...
--
output = reverse("ofni.secnanifxunil" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/internet.html
"Unless there really are chrono-synclastic infundibula. (Roll on the
Church of God the Utterly Indifferent...)" -- Will Deakin