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
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.. |