Re: [HACKERS] Proposal: Local indexes for partitioned table - Mailing list pgsql-hackers

From David Rowley
Subject Re: [HACKERS] Proposal: Local indexes for partitioned table
Date
Msg-id CAKJS1f_BBU2=C6gDaQVXWST+xCcUPsScSmSDPzx+J0cd757udw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Proposal: Local indexes for partitioned table  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On 6 December 2017 at 09:58, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> David Rowley wrote:
>> On 6 December 2017 at 04:29, Robert Haas <robertmhaas@gmail.com> wrote:
>> > How does that proposal keep pg_dump from latching onto the wrong
>> > index, if there's more than one index on the same columns?
>>
>> I'm not hugely concerned about that. It's not a new problem and it's
>> not a problem that I recall seeing anyone complain about, at least not
>> to the extent that we've ever bothered to fix it.
>
> Another reason to do things the proposed way is to let parallel restore
> create the indexes in parallel.  If we just have a single CREATE INDEX
> that cascades to the partitions, that can be run by a single backend
> only, which is a loser.

I'm not all that sure why parallel restore could not work with this.
The leaf partition indexes would all be created first, then the CREATE
INDEX for the partitioned index would just be a metadata change with
some checks to ensure all the leaf partition indexes exist.

> (There's also the fact that you'd lose any COMMENTs etc).

I can't see why that would be a problem with my proposal.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Proposal: Local indexes for partitioned table
Next
From: Erik Rijkers
Date:
Subject: Re: Add RANGE with values and exclusions clauses to the WindowFunctions