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 |
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 |