Re: O(N^3) planning time in choose_plan_name() since 8c49a484e8e

Hi Tom,

On Sat, Oct 31, 2026 at 2:35 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I still don't like this patch too much: it is complicated and not
> clearly correct. For example, consider the case where we've
> generated "expr_1" through "expr_3", and then we encounter a
> user-written name "expr_5". It looks to me like we will consider
> that *not* to match the SubplanNameSuffix for "expr", so we will
> enter "expr_5" as a simple base name in the other list. I think
> that the right things happen afterwards because subplan_name_in_use
> always searches both lists, but this situation is hard to reason
> about and utterly undocumented in the comments. The business about
> strtoul overflow somehow didn't make it into the comments either.

v4, attached, is simpler. It stores all names, as master does, keeps
a suffix counter per base name, and checks a generated name only
against names used as given; not storing the generated names is what
made v3 complicated. The comment says why this is unique, your
"expr_5" case included, and why a counter cannot wrap.

> I still wonder if we couldn't simplify this a great deal by
> abandoning the constraint that the generated names should match
> what the existing code does, along the lines Heikki mentioned.
> I wouldn't want to change that behavior post-19.0, but it's not
> quite too late to consider it now.

I tried that too, with one counter for all names. Robert: then a
sublink that a custom plan folds away renumbers every later subplan,
not only those of its kind, so one prepared statement with
SEQ_SCAN(t2(at)expr_2) seq-scans different subplans in its custom and
generic plans, and pg_plan_advice's own "alternatives" test no longer
matches. v4 keeps today's names: no existing expected output
changes, and a 4000-arm UNION plans in 22 ms (v18 18.6 ms, master
16.9 s) with the same planner memory as master. If you would still
rather have the single counter, that version is ready too.

Regards,
Manu