| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Manu <manuelreyesbravo(at)gmail(dot)com>, Ayoub Kazar <ayoub(dot)kazar(at)data-bene(dot)io>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: O(N^3) planning time in choose_plan_name() since 8c49a484e8e |
| Date: | 2026-11-03 14:21:37 |
| Message-ID: | CA+TgmoZx7rAWBMMEjUnVhvqy8YsRarK8cfouw4DeiRHdgVbuxg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Oct 31, 2026 at 2:36 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
FTR, I don't think there's anything particularly magical about the
names the current code generates. I was aiming to have the code be
clearly correct, and I admit I spent no time worrying about cases with
4000 subqueries. Hence, it's fine with me if we change the algorithm,
but I agree that should ideally only be done as part of a major
release. The complicated part is making sure that generated names
don't collide with user-written names that might happen to have the
same format. It's also important that the set of names we end up with
doesn't depend on what the planner chooses to do. We want expr_5 to
mean the same thing no matter how the query gets planned, because
advice strings can refer to it.
I don't see an email from Heikki in this thread so I'm not sure what
that proposal was specifically.
--
Robert Haas
Databricks
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Burd | 2026-11-03 14:34:16 | Re: [RFC] Property-based testing for Postgres |
| Previous Message | Heikki Linnakangas | 2026-11-03 14:12:29 | Re: Assertion with aborted UPDATE in subtransaction |