Re: why postgresql over other RDBMS

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, "Ron Johnson" <ron(dot)l(dot)johnson(at)cox(dot)net>, "pgsql-general General" <pgsql-general(at)postgresql(dot)org>
Subject: Re: why postgresql over other RDBMS
Date: 2007-07-17 03:12:05
Message-ID: 87ps2renay.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Bruce Momjian" <bruce(at)momjian(dot)us> writes:

> Matthew T. O'Connor wrote:
>> Bruce Momjian wrote:
>> >
>> > * Allow multiple indexes to be created concurrently, ideally via a
>> > single heap scan, and have a restore of a pg_dump somehow use it

Actually, the sync scan patch ought to make this more or less happen
magically. If you start a bunch of concurrent index builds they will try to
scan the table together.

There's no useful way for pg_dump to make use of this since it only has one
backend. And you still need to generate n copies of the data for sorting. And
performing n sorts in parallel won't be as cache efficient as doing them one
after the other. So there's still a use case for the TODO

But the hole is not nearly as urgent as before. You can get most of the
benefit if you really need it by rolling your own. And the cool thing is some
people already have rolled their own and they'll just magically see an
improvement. They don't have to do anything they weren't doing already to turn
it on.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2007-07-17 03:27:32 Re: why postgresql over other RDBMS
Previous Message Tom Lane 2007-07-17 01:43:53 Re: Issues with PL/PGSQL function..