On Mon, Dec 4, 2017 at 6:57 PM, David Rowley <david.row...@2ndquadrant.com> wrote: > On 2 December 2017 at 03:39, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Nov 30, 2017 at 11:39 PM, David Rowley >> <david.row...@2ndquadrant.com> wrote: >>> I feel like we could do better here with little extra effort. The >>> DETACH index feature does not really seem required for this patch. >> >> Because of the dump/restore considerations mentioned in >> http://postgr.es/m/ca+tgmobuhghg9v8saswkhbbfywg5a0qb+jgt0uovq5ycbdu...@mail.gmail.com >> I believe we need a way to create the index on the parent without >> immediately triggering index builds on the children, plus a way to >> create an index on a child after-the-fact and attach it to the parent. >> Detach isn't strictly required, but why support attach and not detach? > > 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? > My primary reason for not liking this way is around leaving indexes > around as indisvalid=false, however, I suppose that an index could be > replaced atomically with a DETACH and ATTACH within a single > transaction. I had previously not really liked the idea of > invalidating an index by DETACHing a leaf table's index from it. Of > course, this patch does nothing special with partitioned indexes, but > I believe one day we will want to do something with these and that the > DETACH/ATTACH is not the best design for replacing part of the index. What do you propose? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
