On 8 December 2017 at 10:51, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Dec 7, 2017 at 4:43 PM, David Rowley
> <david.rowley@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.
That's true, but is it worth inventing/maintaining an ATTACH syntax
for that? It's not a very common case that multiple matching indexes
existing. If it is worth it, do we need DETACH at all?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
