On Thu, Dec 7, 2017 at 4:43 PM, David Rowley <david.row...@2ndquadrant.com> wrote: > And yeah, this does nothing for making sure we choose the correct > index if more than one matching index exists on the leaf partition, > but perhaps we can dump a series of > > ALTER INDEX p_a_idx REPLACE INDEX FOR p1 WITH p1_a_idx; > ALTER INDEX p_a_idx REPLACE INDEX FOR p2 WITH p2_a_idx; > > ... which would be no-ops most of the time, but at least would ensure > we use the correct index. (Likely we could fix the FOREIGN KEY > constraint choosing the first matching index with some variation of > this syntax)
Sure, that would fix the problem I'm concerned about, but creating the parent index first, as a shell, and then creating each child and attaching it to the parent *also* fixes the problem I'm concerned about, and without dragging any bystander objects into the fray. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
