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. 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. [1] https://www.postgresql.org/message-id/CAKJS1f_o6v%2BXtT%2B3gfieUdCiU5Sn84humT-CVW5So_x_f%3DkLxQ%40mail.gmail.com -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
