| From: | Robert Haas <rhaas(at)postgresql(dot)org> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Add an alternative_plan_name field to PlannerInfo. |
| Date: | 2026-03-26 20:54:34 |
| Message-ID: | E1w5rir-001anW-2f@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Add an alternative_plan_name field to PlannerInfo.
Typically, we have only one PlannerInfo for any given subquery, but
when we are considering a MinMaxAggPath or a hashed subplan, we end
up creating a second PlannerInfo for the same portion of the query,
with a clone of the original range table. In fact, in the MinMaxAggPath
case, we might end up creating several clones, one per aggregate.
At present, there's no easy way for a plugin, such as pg_plan_advice,
to understand the relationships between the original range table and
the copies of it that are created in these cases. To fix, add an
alternative_plan_name field to PlannerInfo. For a hashed subplan, this
is the plan name for the non-hashed alternative; for minmax aggregates,
this is the plan_name from the parent PlannerInfo; otherwise, it's the
same as plan_name.
Discussion: http://postgr.es/m/CA+TgmoYuWmN-00Ec5pY7zAcpSFQUQLbgAdVWGR9kOR-HM-fHrA@mail.gmail.com
Reviewed-by: Lukas Fittl <lukas(at)fittl(dot)com>
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/26255a320733de2d91a30bd6ae529dd01e7f3409
Modified Files
--------------
src/backend/optimizer/path/allpaths.c | 2 +-
src/backend/optimizer/plan/planagg.c | 1 +
src/backend/optimizer/plan/planner.c | 15 +++++++++++----
src/backend/optimizer/plan/subselect.c | 6 +++---
src/backend/optimizer/prep/prepjointree.c | 1 +
src/backend/optimizer/prep/prepunion.c | 2 +-
src/include/nodes/pathnodes.h | 12 ++++++++++++
src/include/optimizer/planner.h | 1 +
8 files changed, 31 insertions(+), 9 deletions(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-03-26 21:22:52 | pgsql: pg_plan_advice: Invent DO_NOT_SCAN(relation_identifier). |
| Previous Message | Tom Lane | 2026-03-26 19:14:46 | pgsql: Doc: commit performs rollback of aborted transactions. |