David Rowley wrote: > So, then this patch is only really intended as a syntax shortcut for > mass adding of indexes to each partition?
This patch is intended to serve as a basis on which to construct further features, just like every other patch we apply. > I feel like we could do better here with little extra effort. The > DETACH index feature does not really seem required for this patch. I > think just ensuring a matching index exists on each leaf partition and > creating any which don't exist before creating the index on the target > partitioned table seems like the correct solution. That way we can > make that index indisvalid flag have a valid meaning all the time. > Some later patch can invent some way to replace a bloated index. What you're saying is that I've written code for A+B, and you're "interested in C (which is incompatible with B), so can we have A+C and drop B". But in reality, there exists (unwritten) D that solves the incompatiblity between B and C. I'm just saying it's essentially the same to postpone C+D than to postpone B+D, and I already have B written; plus that way we don't have to come up with some novel way to handle pg_dump support. So can we get A+B committed and discuss C+D later? A = partitioned indexes B = pg_dump support based on ATTACH C = your proposed planner stuff D = correct indisvalid setting for partitioned indexes (set to false when a partition does not contain the index) The patch in this thread is A+B. > Perhaps later we can invent some generic way to replace a physical > leaf index for a given partitioned index perhaps with the same patch > that might allow us to replace an index which is used by a constraint, > which to me seems like a feature we should have had years ago. This is a hypothetical feature E which would be nice (for partitioned indexes and for ordinary indexes too) but is not strictly necessary. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services