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 have been following this discussion on the regression related to commit
92fe23d93aa (skip scan in nbtree), and I ran some tests on my side to
understand it better.
Observations :
-
I reproduced Tomas’s pgbench test with a simple workload on a
single-column index,
SELECT count(*) FROM pgbench_accounts WHERE bid = 0;
-
Throughput with the skip-scan build was consistently ~40–50% lower
compared to pre-patch builds.
-
After setting MALLOC_TOP_PAD_= 64MB, the performance gap disappeared
almost entirely, confirming that the issue is allocator overhead from
frequent malloc/free calls rather than the skip-scan logic itself.
Reproduction steps :
Here is the exact setup I used (very close to Tomas’s):
# init database
pg_ctl -D data init
pg_ctl -D data -l pg.log start
createdb test
# create table and index
psql test -c 'CREATE TABLE pgbench_accounts (aid int, bid int,
abalance int, filler text);'
psql test -c 'CREATE INDEX ON pgbench_accounts(bid);'
# load pgbench data (scale 1)
pgbench -i -s 1 test
# custom query file (select.sql)echo "SELECT count(*) FROM
pgbench_accounts WHERE bid = 0;" > select.sql
# run benchmarksfor m in simple prepared; do
for c in 1 4 32; do
pgbench -n -f select.sql -M $m -T 10 -c $c -j $c test | grep tps;
done;done
When running the above, the skip-scan build consistently showed ~50% lower
tps compared to pre-patch, unless MALLOC_TOP_PAD_ was increased.
Thoughts on causes :
-
The increase in IndexAmRoutine size seems to push the cache structures
past glibc’s small-heap thresholds, forcing more system allocations.
-
As Tomas noted, this is fragile: even if we drop the unused options
support proc, future extensions to the struct could trigger the same issue
again.
Suggestions / possible directions :
1.
*Short term (PG18) *:
-
If we want a low-risk change, removing the unused options support
function may be acceptable, but I agree it feels like a
temporary band-aid.
-
Alternatively, shipping PG18 as-is with a release note warning about
allocator sensitivity might be the safest option.
2.
*Longer term (PG19) *:
-
Explore *static allocation of IndexAmRoutine* instead of per-AM
dynamic allocation. This should eliminate repeated malloc churn.
-
Add a micro-benchmark or regression test that stresses catalog cache
growth and malloc behavior (similar to pgbench with many partitions), so
allocator-driven regressions are detected earlier.
-
Consider documenting allocator tuning (MALLOC_TOP_PAD_) as a
workaround until the structural fix lands.
Closing :
I don’t have a final patch proposal at this stage, but I would like to help
test any candidate fixes or prototypes. If there’s interest, I can also
contribute a self-contained benchmark script for regression testing.
Regards,
Athiyaman
