From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: more than one index in a single heap pass? |
Date: | 2009-07-14 23:32:05 |
Message-ID: | 4A5D1575.1070602@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark wrote:
> On Tue, Jul 14, 2009 at 8:50 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>>
>>> Andrew Dunstan wrote:
>>>
>>>> I was just wondering idly today if we could usefully build a number of
>>>> indexes at the same time in a single pass over the heap, or could it be
>>>> that we wouldn't gain much? I haven't even got around to thinking about
>>>> any syntax for it.
>>>>
>>> Could we make it work on two backends building one index each in
>>> synchronized scans?
>>>
>> Don't we more or less have that already?
>>
>
> Wasn't that a big part of the point of the "parallel pg_restore" feature?
>
>
Well, yes, it's some of it, and in theory Tom's late addition of a queue
that gets all the dependencies of a table as soon as the table data is
restored should make that work better. But of course, that's not the
only time indexes are created, and each index creation command will be
doing its own heap processing, albeit that synchronised scanning will
make that lots cheaper.
As I said originally, it was just an idle thought that came to me today.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Glen Parker | 2009-07-15 00:01:15 | Re: more than one index in a single heap pass? |
Previous Message | Richard Huxton | 2009-07-14 23:27:32 | Re: navigation menu for documents |