Re: [HACKERS] Proposal: Local indexes for partitioned table

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Maksim Milyutin <milyutinma(at)gmail(dot)com>
Subject: Re: [HACKERS] Proposal: Local indexes for partitioned table
Date: 2017-12-05 20:58:24
Message-ID: 20171205205824.d7yrpev7fyz2w6lr@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley wrote:
> On 6 December 2017 at 04:29, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Mon, Dec 4, 2017 at 6:57 PM, David Rowley
> >> I proposed that this worked a different way in [1]. I think the way I
> >> mention is cleaner as it means there's no extra reason for a
> >> partitioned index to be indisvalid=false than there is for any other
> >> normal index.
> >
> > 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.

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

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2017-12-05 20:59:33 Re: compress method for spgist - 2
Previous Message David Rowley 2017-12-05 20:53:03 Re: [HACKERS] Proposal: Local indexes for partitioned table