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
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 |