Re: more than one index in a single heap pass?

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

In response to

Responses

Browse pgsql-hackers by date

  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