Horton

Re: Returning nbtree posting list TIDs in DESC order during backwards scans

Peter Geoghegan <pg@bowt.ie>

View thread
From: Peter Geoghegan <pg@bowt.ie>
To: Victor Yegorov <vyegorov@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-11T01:51:24Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Clarify why _bt_killitems sorts its items array.

  2. Return TIDs in desc order during backwards scans.

  3. Optimize nbtree backwards scans.

  4. Optimize nbtree backward scan boundary cases.

On Wed, Dec 10, 2025 at 5:33 PM Peter Geoghegan <pg@bowt.ie> wrote:
> I did have a comment like that at one point, but I felt that it didn't
> quite make sense to keep it. Such a comment would address how things
> used to work, not how they work now (also how they really should have
> worked all along).

On second thought, you (Victor) had this right: we really should have
such a comment.

I must have forgotten that the loop in _bt_killitems doesn't iterate
through so->currPos.items[] directly; it iterates through
killedItems[]. Earlier versions of the patch (that fully got rid of
killedItems) *directly* looped over so->currPos.items[], but the
committed version doesn't work that way.

I pushed a commit just now that adds a comment to clarify the
situation. It specifically mentions posting list tuples, per your
suggestion. (The commit also adds a documenting assertion to verify
leaf page order within the _bt_killitems loop.)

Thanks
-- 
Peter Geoghegan