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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, 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-15 14:45:56
Message-ID: 200907151445.n6FEjuT23471@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan wrote:
> > 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.

Well, TODO has:

Allow multiple indexes to be created concurrently, ideally via a
single heap scan, and have pg_restore use it

Isn't this already largely done by parallel pg_restore work?

so we have to decide if we still want that item. I think what we don't
have is a way to create multiple indexes simultaneously via SQL.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-15 14:53:24 Re: more than one index in a single heap pass?
Previous Message Bernd Helmle 2009-07-15 14:13:43 Re: [PATCH 3/3] Document geqo_seed variable.