Thread

Re: Adding skip scan (including MDAM style range skip scan) to nbtree

BharatDB <bharatdbpg@gmail.com> — 2025-09-09T05:14:16Z

Dear Team,

With reference to the conversation ongoing in message ID :
c562dc2a-6e36-46f3-a5ea-cd42eebd7118, I am writing to express my interest
in contributing to the ongoing work on fixing the bug related to Adding
skip scan (including MDAM style range skip scan) to nbtree.

I tried to replicate the performance regression reported earlier in this
thread, by running pgbench with the same setup (pgbench scale=1, 100
partitions, extra index on bid, single-count query). I built both before
skip scan (commit 3ba2cdaa454) and after skip scan (commit 92fe23d93aa)
versions, and compared the throughput:

--- BEFORE (3ba2cdaa454) ---
Mode=simple Clients=1   tps = 23890
Mode=simple Clients=4   tps = 82791
Mode=simple Clients=32  tps = 129877
Mode=prepared Clients=1 tps = 26404
Mode=prepared Clients=4 tps = 87116
Mode=prepared Clients=32 tps = 140881

--- AFTER (92fe23d93aa) ---
Mode=simple Clients=1   tps = 22551
Mode=simple Clients=4   tps = 76844
Mode=simple Clients=32  tps = 129445
Mode=prepared Clients=1 tps = 25880
Mode=prepared Clients=4 tps = 84876
Mode=prepared Clients=32 tps = 137812

In my environment the regression is smaller than Tomas originally
observed (*~5–8%
vs. ~50%*), but it still shows up consistently, especially at higher
concurrency.

This suggests that the extra malloc/free activity in the skip scan code
path is indeed introducing overhead, though the impact seems to vary
depending on glibc/memory allocator behavior.

*Proposal:*

   -

   For PG18, a safe short-term fix could be to *remove the unused “options”
   support function*, as Peter suggested, or replace it with a lighter path
   that avoids repeated allocations.
   -

   Longer term, we may want to *revisit skip scan memory management* (e.g.,
   static allocation, memory pool, or reducing per-call overhead) so that the
   optimization does not regress performance in micro-benchmarks.

I am currently working on these proposed methods and will continue
experimenting to provide further results and possible patches.

Regards,
Athiyaman