Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table.

On Mon, Sep 15, 2025 at 12:15 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thanks for weighing in! Opinions are good, and I'm by no means set
> on doing what is in my submitted patch. However, I'm failing to
> extract a clearly-better alternative from your message.

Oh, you wanted an *actionable* opinion? :-)

> I think I'm not getting something here. Isn't that inconsistency
> directly traceable to the user having supplied inconsistent names
> to begin with?

I don't think so. The user's create index commands in this example are:

create index idxparti on idxpart (a);
create index idxparti2 on idxpart (c, b);
create index on idxpart2 (a);
create index on idxpart2 (c, b);

I don't see anything inconsistent there. Granted, they could have
spelled out the index names for idxpart2, but the point from my POV is
that the index names here are fine without the patch, and yet the
patch changes them. At least AFAICS, the only issue we currently have
is when there are expression indexes involved, and more than one of
them.

> Maybe what your complaint
> really points to is that this regression test case is designed around
> the old naming conventions, and we ought to do more-extensive surgery
> on it so that the names that are test-script-determined are consistent
> with the new approach.

There's arguably some of this, but I don't see it as the main issue.

> > Now, what about
> > the absolute quality of the names? The change makes the index names
> > more consistent with the name of the index on the parent, which is
> > nice, but we also lose something: the index names are now less
> > consistent with the names of the child tables, and they don't mention
> > the affected columns any more.
>
> Well, again, that's a user decision.

Not when the names are system-generated -- we of course must adhere to
the user's choice of names, but we can't blame the user if we start
generating inferior names.

> > Surely, it's not as nice for the indexes on the brassica and daucus
> > tables to be named vegetables_id_idx_1 and vegetables_id_idx_2 rather
> > than brasica_id_ix and daucus_id_idx. That's just gotta be worse.
>
> I don't really agree. The only thing the overexplain test script
> does to create these indexes is
>
> CREATE INDEX ON vegetables (id);
>
> I don't see why it's even slightly surprising that the resulting
> child indexes should have names involving "vegetables" and "id".
> If anything, I'd argue that the current behavior is more surprising,
> even if we've grown used to it.

OK. So that's a difference of opinion on what looks best then, which
is fair enough.

> So, how do we move forward? I'm perfectly willing to look into
> the derive-a-name-from-the-expression idea, but I think that'd
> best be done in a separate patch.

I'm not sure. To me, the munging of everything together under the name
"expr" is the root of the problem here, and since this patch isn't
really addressing that problem, it's kind of to one side of what I see
as the main point. However, that's a judgement call, and if you or
others see it differently, then so be it.

--
Robert Haas
EDB: http://www.enterprisedb.com