Re: plan shape work

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexandra Wang <alexandra(dot)wang(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "bruce(at)momjian(dot)us" <bruce(at)momjian(dot)us>, lepihov(at)gmail(dot)com
Subject: Re: plan shape work
Date: 2025-09-26 14:23:29
Message-ID: CA+TgmoYEzxfcqhi6EqoLznqmRmpM0CMRkA7SX_gJWAD_rLvq=Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 26, 2025 at 2:29 AM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> Looking at choose_plan_name(), IIUC, the nested loop is used to find
> the next unused suffix number for a given name. I'm wondering why not
> simply iterate through glob->subplanNames once, check the suffix
> number for each name matching the given base name, determine the
> current maximum suffix, and then use "max_suffix + 1" as the next
> unused suffix. This approach requires only a single pass through the
> list, and if there's a bug, the worst-case scenario would be a
> duplicate name rather than an infinite loop. It seems to me that this
> approach is both more efficient and less risky.

I feel like the current coding is more straightforward and this should
be considered in terms of the chance of having bugs. Doing as you
propose here would require starting with a prefix match of the string
and then attempting a string-to-integer conversion on the remaining
bytes. That's certainly doable but such things tend to be a bit
fiddly: you have to make sure you do the right thing when you see a
non-digit and when the value overflows or is zero. It wouldn't be that
hard to get it right, but I think it would be a little trickier than
we have now. If we find that the performance cost of this function is
too high in some scenario, replacing it within an implementation along
these lines would make sense to me, but I am not too worried about the
current logic accidentally causing an infinite loop. I don't think
that will happen but even if it does it should be a simple fix.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mihail Nikalayeu 2025-09-26 14:27:12 Re: Adding REPACK [concurrently]
Previous Message Tom Lane 2025-09-26 14:23:21 Re: plan shape work