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
