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/5685~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/5685
Choose a head ref
  • 4 commits
  • 19 files changed
  • 2 contributors

Commits on May 1, 2025

  1. Expand virtual generated columns before sublink pull-up 

    Currently, we expand virtual generated columns after we have pulled up
any SubLinks within the query's quals.  This ensures that the virtual
generated column references within SubLinks that should be transformed
into joins are correctly expanded.  This approach works well and has
posed no issues.

In an upcoming patch, we plan to centralize the collection of catalog
information needed early in the planner.  This will help avoid
repeated table_open/table_close calls for relations in the rangetable.
Since this information is required during sublink pull-up, we are
moving the expansion of virtual generated columns to occur beforehand.

To achieve this, if any EXISTS SubLinks can be pulled up, their
rangetables are processed just before pulling them up.
    @guofengrichard
    guofengrichard authored and Commitfest Bot committed May 1, 2025
    Configuration menu
    Copy the full SHA
    6a850b7 View commit details
    Browse the repository at this point in the history

  2. Centralize collection of catalog info needed early in the planner 

    There are several pieces of catalog information that need to be
retrieved for a relation during the early stage of planning.  These
include relhassubclass, which is used to clear the inh flag if the
relation has no children, as well as a column's attgenerated and
default value, which are needed to expand virtual generated columns.
More such information may be required in the future.

Currently, these pieces of catalog data are collected in multiple
places, resulting in repeated table_open/table_close calls for each
relation in the rangetable.  This patch centralizes the collection of
all required early-stage catalog information into a single loop over
the rangetable, allowing each relation to be opened and closed only
once.
    @guofengrichard
    guofengrichard authored and Commitfest Bot committed May 1, 2025
    Configuration menu
    Copy the full SHA
    bfc727c View commit details
    Browse the repository at this point in the history

  3. Reduce "Var IS [NOT] NULL" quals during constant folding 

    In commit b262ad4, we introduced an optimization that reduces an IS
[NOT] NULL qual on a NOT NULL column to constant true or constant
false, provided we can prove that the input expression of the NullTest
is not nullable by any outer joins or grouping sets.  This deduction
happens quite late in the planner, during the distribution of quals to
rels in query_planner.  However, this approach has some drawbacks: we
can't perform any further folding with the constant, and it turns out
to be prone to bugs.

Ideally, this deduction should happen during constant folding.
However, the per-relation information about which columns are defined
as NOT NULL is not available at that point.  This information is
currently collected from catalogs when building RelOptInfos for base
or "other" relations.

This patch moves the collection of NOT NULL attribute information for
relations before pull_up_sublinks, storing it in a hash table keyed by
relation OID.  It then uses this information to perform the NullTest
deduction for Vars during constant folding.  This also makes it
possible to leverage this information to pull up NOT IN subqueries.

Note that this patch does not get rid of restriction_is_always_true
and restriction_is_always_false.  Removing them would prevent us from
reducing some IS [NOT] NULL quals that we were previously able to
reduce, because (a) the self-join elimination may introduce new IS NOT
NULL quals after constant folding, and (b) if some outer joins are
converted to inner joins, previously irreducible NullTest quals may
become reducible.
    @guofengrichard
    guofengrichard authored and Commitfest Bot committed May 1, 2025
    Configuration menu
    Copy the full SHA
    59f10c3 View commit details
    Browse the repository at this point in the history

  4. [CF 5685] v4 - Reduce "Var IS [NOT] NULL" quals during constant folding 

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

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

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/CAMbWs4_pqSz5rqi_Rs1xCiBwN8_CBrzWnjT_JAZFu9wUtSrB7Q@mail.gmail.com
Author(s): Richard Guo
    Commitfest Bot committed May 1, 2025
    Configuration menu
    Copy the full SHA
    eee54b4 View commit details
    Browse the repository at this point in the history
Loading