pgsql: Store information about elided nodes in the final plan.

From: Robert Haas <rhaas(at)postgresql(dot)org>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Store information about elided nodes in the final plan.
Date: 2026-02-10 22:19:15
Message-ID: E1vpw4g-0003OO-2p@gemulon.postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Store information about elided nodes in the final plan.

An extension (or core code) might want to reconstruct the planner's
choice of join order from the final plan. To do so, it must be possible
to find all of the RTIs that were part of the join problem in that plan.
Commit adbad833f3d9e9176e8d7005f15ea6056900227d, together with the
earlier work in 8c49a484e8ebb0199fba4bd68eaaedaf49b48ed0, is enough to
let us match up RTIs we see in the final plan with RTIs that we see
during the planning cycle, but we still have a problem if the planner
decides to drop some RTIs out of the final plan altogether.

To fix that, when setrefs.c removes a SubqueryScan, single-child Append,
or single-child MergeAppend from the final Plan tree, record the type of
the removed node and the RTIs that the removed node would have scanned
in the final plan tree. It would be natural to record this information
on the child of the removed plan node, but that would require adding an
additional pointer field to type Plan, which seems undesirable. So,
instead, store the information in a separate list that the executor need
never consult, and use the plan_node_id to identify the plan node with
which the removed node is logically associated.

Also, update pg_overexplain to display these details.

Reviewed-by: Lukas Fittl <lukas(at)fittl(dot)com>
Reviewed-by: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
Reviewed-by: Greg Burd <greg(at)burd(dot)me>
Reviewed-by: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Reviewed-by: Amit Langote <amitlangote09(at)gmail(dot)com>
Reviewed-by: Haibo Yan <tristan(dot)yim(at)gmail(dot)com>
Reviewed-by: Alexandra Wang <alexandra(dot)wang(dot)oss(at)gmail(dot)com>
Discussion: http://postgr.es/m/CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/0d4391b265f83023d0b7eed71817517410f76e60

Modified Files
--------------
contrib/pg_overexplain/expected/pg_overexplain.out | 16 +++++--
contrib/pg_overexplain/pg_overexplain.c | 39 ++++++++++++++++
src/backend/optimizer/plan/planner.c | 1 +
src/backend/optimizer/plan/setrefs.c | 52 +++++++++++++++++++++-
src/include/nodes/pathnodes.h | 3 ++
src/include/nodes/plannodes.h | 20 +++++++++
src/tools/pgindent/typedefs.list | 1 +
7 files changed, 127 insertions(+), 5 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Michael Paquier 2026-02-10 22:34:11 pgsql: Improve type handling of varlena structures
Previous Message Robert Haas 2026-02-10 21:32:29 pgsql: Store information about range-table flattening in the final plan