Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: cf/5998~1
Choose a base ref
...
head repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: cf/5998
Choose a head ref
  • 2 commits
  • 35 files changed
  • 3 contributors

Commits on Oct 7, 2025

  1. Assign each subquery a unique name prior to planning it. 

    Previously, subqueries were given names only after they were planned,
which makes it difficult to use information from a previous execution of
the query to guide future planning. If, for example, you knew something
about how you want "InitPlan 2" to be planned, you won't know whether
the subquery you're currently planning will end up being "InitPlan 2"
until after you've finished planning it, by which point it's too late to
use the information that you had.

To fix this, assign each subplan a unique name before we begin planning
it. To improve consistency, use textual names for all subplans, rather
than, as we did previously, a mix of numbers (such as "InitPlan 1") and
names (such as "CTE foo"), and make sure that the same name is never
assigned more than once.

We adopt the somewhat arbitrary convention of using the type of sublink
to set the plan name; for example, a query that previously had two
expression sublinks shown as InitPlan 2 and InitPlan 1 will now end up
named expr_1 and expr_2. Because names are assigned before rather than
after planning, some of the regression test outputs show the numerical
part of the name switching positions: what was previously SubPlan 2 was
actually the first one encountered, but we finished planning it later.

We assign names even to subqueries that aren't shown as such within the
EXPLAIN output. These include subqueries that are a FROM clause item or
a branch of a set operation, rather than something that will be turned
into an InitPlan or SubPlan. The purpose of this is to make sure that,
below the topmost query level, there's always a name for each subquery
that is stable from one planning cycle to the next (assuming no changes
to the query or the database schema).

Author: Robert Haas <[email protected]>
Co-authored-by: Tom Lane <[email protected]>
Reviewed-by: Alexandra Wang <[email protected]>
Reviewed-by: Richard Guo <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Reviewed-by: Junwang Zhao <[email protected]>
Discussion: http://postgr.es/m/[email protected]
    @robertmhaas @tglsfdc
    2 people authored and Commitfest Bot committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    ef15851 View commit details
    Browse the repository at this point in the history

  2. [CF 5998] v11 - plan shape work 

    This branch was automatically generated by a robot using patches from an
email thread registered at:

https://commitfest.postgresql.org/patch/5998

The branch will be overwritten each time a new patch version is posted to
the thread, and also periodically to check for bitrot caused by changes
on the master branch.

Patch(es): https://www.postgresql.org/message-id/CA+Tgmobe4AR6wZL-EQtN7JByJHxaaaQeBCd_MW5TYmOzQfMuEA@mail.gmail.com
Author(s): Robert Haas
    Commitfest Bot committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    5347cac View commit details
    Browse the repository at this point in the history
Loading