Re: Adding skip scan (including MDAM style range skip scan) to nbtree - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Adding skip scan (including MDAM style range skip scan) to nbtree
Date
Msg-id CAH2-WzknOSR9Eeov1Bvrcn1kFKoxDmXHmUMO0G7G5JYEOdLGBA@mail.gmail.com
Whole thread Raw
In response to Re: Adding skip scan (including MDAM style range skip scan) to nbtree  (Natalya Aksman <natalya@tigerdata.com>)
Responses Re: Adding skip scan (including MDAM style range skip scan) to nbtree
List pgsql-hackers
On Wed, Sep 10, 2025 at 2:59 PM Natalya Aksman <natalya@tigerdata.com> wrote:
> But after btrescan resets "so->numberOfKeys = 0", so->skipScan is not reset to "false" in  _bt_preprocess_keys
becauseof this code:
https://github.com/postgres/postgres/blob/9016fa7e3bcde8ae4c3d63c707143af147486a10/src/backend/access/nbtree/nbtpreprocesskeys.c#L1847
> After we set "so->numberOfKeys = 0" we quit on line 1847 before we get to the line 1874 where we do "so->skipScan =
(numSkipArrayKeys> 0);"
https://github.com/postgres/postgres/blob/9016fa7e3bcde8ae4c3d63c707143af147486a10/src/backend/access/nbtree/nbtpreprocesskeys.c#L1874

It sounds like the patch that I posted fixes the problem, without you
having to set so->skipScan externally (which sounds like a big
kludge). Can you confirm that it actually does fix the problem that
you're seeing?

TimescaleDB isn't following the letter of the law here. But I do still
see the argument for consistently setting so->skipScan during
preprocessing. That at least makes sense on general robustness
grounds.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Arseniy Mukhin
Date:
Subject: Re: Proposal: Out-of-Order NOTIFY via GUC to Improve LISTEN/NOTIFY Throughput
Next
From: Bharath Rupireddy
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication