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/5896~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/5896
Choose a head ref
  • 2 commits
  • 1 file changed
  • 2 contributors

Commits on Sep 15, 2025

  1. Teach nbtree to avoid evaluating row compare keys. 

    Add logic to _bt_set_startikey that determines whether row compare
keys are guaranteed to be satisfied by every tuple on a page that is
about to be read by _bt_readpage.  This works in largely the same way as
the existing scalar inequality logic.  Testing has shown that this
significantly improves performance in cases where pstate.startikey can
safely be set to an offset beyond a row compare's so->keyData[] offset.

_bt_set_startikey is now feature complete: there's no remaining kind of
scan key that lacks support.  All nbtree scan keys work in essentially
the same way (though with slightly different rules for inequalities and
equalities), so it should be feasible to add _bt_set_startikey support
for new kinds of scan keys that have yet to be invented.

Also stop refusing to set pstate.startikey to an offset beyond any
nonrequired key (don't add logic that'll do that for an individual row
compare subkeys, either).  We can fully rely on "firstchangingattnum"
tests instead.  This is safe because we can only conclude that an
inequality key is guaranteed to be satisfied by every tuple from a given
leaf page when the deciding attribute is the first attribute whose
values change across all of the tuples from the page (or when it's some
earlier/higher-order attribute, with only one distinct tuple value).

Follow up to commit 8a51027, which added the _bt_set_startikey
optimization.

Author: Peter Geoghegan <[email protected]>
Reviewed-By: Chao Li <[email protected]>
Discussion: https://postgr.es/m/CAH2-WznL6Z3H_GTQze9d8T_Ls=cYbnd-_9f-Jo7aYgTGRUD58g@mail.gmail.com
    @petergeoghegan
    petergeoghegan authored and Commitfest Bot committed Sep 15, 2025
    Configuration menu
    Copy the full SHA
    578cb20 View commit details
    Browse the repository at this point in the history

  2. [CF 5896] v2 - Adding support for Row Compares to nbtree startikey op… 

    …timization

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

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

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/CAH2-WzmCLEJ8Zh+MrmrLDy+Z_zQme--p+exqfJvrV4O6m2dgaw@mail.gmail.com
Author(s): Peter Geoghegan
    Commitfest Bot committed Sep 15, 2025
    Configuration menu
    Copy the full SHA
    141335f View commit details
    Browse the repository at this point in the history
Loading