From: | Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> |
---|---|
To: | pgsql-general General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: why postgresql over other RDBMS |
Date: | 2007-06-01 21:07:15 |
Message-ID: | 46608A83.9010305@cox.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 06/01/07 11:22, Bruce Momjian wrote:
> PFC wrote:
>> On Thu, 31 May 2007 22:20:09 +0200, Vivek Khera <vivek(at)khera(dot)org> wrote:
>>
>>> On May 25, 2007, at 5:28 PM, Tom Lane wrote:
>>>
>>>> That's true at the level of DDL operations, but AFAIK we could
>>>> parallelize table-loading and index-creation steps pretty effectively
>>>> --- and that's where all the time goes.
>>> I would be happy with parallel builds of the indexes of a given table.
>>> That way you have just one scan of the whole table to build all its
>>> indexes.
>> Will the synchronized seq scan patch be able to do this by issuing all
>> the CREATE INDEX commands at the same time from several different database
>> connections ?
>
> No, but it could someday.
Or would a "CREATE MANY INDEXES" (where in one statement you specify
all the indexes on a single table) command be easier to implement?
This way also the process reads the table once, building separate
sortwork files on-the-fly. Too bad child processes can't inherit
transaction state.
--
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Staubo | 2007-06-01 21:08:50 | Re: Slightly OT. |
Previous Message | Kevin Hunter | 2007-06-01 21:03:17 | Re: Seq Scan |