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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Mircea Cadariu <cadariu(dot)mircea(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Returning nbtree posting list TIDs in DESC order during backwards scans
Date: 2025-07-17 19:37:31
Message-ID: CAH2-Wzn3Qu6XcLUF++ZpHWWOXO--2dFZgXbhnuC-H8krvH=3sA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 17, 2025 at 2:26 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> The loop has an early check for this (for non-itemDead entries) here:
>
> /* Quickly skip over items never ItemDead-set by btgettuple */
> if (!kitem->itemDead)
> continue;
>
> I really doubt that this matters

I think that this patch isn't too far off being committable. I'll need
to think about issues around adding the new kitem->itemDead bitfield.
I'm not really worried about _bt_killitems; more so about the routines
called by _bt_readpage, which must make sure that the bit is unset
every time a TID is saved in so->currPos.items[].

Attached is v3. Not much has changed. We now defensively unset each
previously set kitem->itemDead within _bt_killitems. I've also added a
pair of macros that represent 0 and 1 values for these kitem->itemDead
bits.

Thanks
--
Peter Geoghegan

Attachment Content-Type Size
v3-0001-Return-TIDs-in-desc-order-during-backwards-scans.patch application/octet-stream 16.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-07-17 19:42:27 Re: POC: Parallel processing of indexes in autovacuum
Previous Message Jeff Davis 2025-07-17 18:59:14 Re: Collation and primary keys