Re: index prefetching
Andres Freund <andres@anarazel.de>
Hi, On 2026-02-15 00:13:39 +0000, Alexandre Felipe wrote: > For the tests, I disable sorting, sequential scans, index only scans and > bitmap scans. > Since buffer cache always has a significant impact on the query > performance, I shuffled the tests, and tried to adjust for the number of > buffer hit/read, but later I found that the best way to control that was to > use a table small enough to be entirely held in cache, and evict the > buffers. I doubt that shuffling the tests will provide meaningful uncached performance in a test like this - your data size is tiny, so there's simply not a whole lot of data, i.e. it all stays cached. Which is also what is going to limit the amount of benefit from prefetching you're going to get. Evicting from the postgres buffercache won't do much, because you're not going to evict it from the kernel cache, so there's no actual IO that prefetching can avoid. I think generally your queries are not particularly IO bound, due to the small size. I've adapted your data creation script to create a table with the number of rows suffixed and created it for 100k and 1M rows. 100k rows: prefetching=0: Index Scan using idx_periodic_100000 on prefetch_test_data_100000 (cost=0.29..15351.09 rows=100000 width=8) (actual time=0.026..201.730 rows=100000.00 loops> Index Searches: 1 Buffers: shared hit=96875 read=3400 I/O Timings: shared read=32.727 Planning: Buffers: shared hit=81 read=23 I/O Timings: shared read=1.521 Planning Time: 1.851 ms Execution Time: 207.031 ms prefetching=1: Index Scan using idx_periodic_100000 on prefetch_test_data_100000 (cost=0.29..15351.09 rows=100000 width=8) (actual time=0.209..193.508 rows=100000.00 loops=1) Index Searches: 1 Buffers: shared hit=96875 read=3400 I/O Timings: shared read=29.830 Planning: Buffers: shared hit=81 read=23 I/O Timings: shared read=1.962 Planning Time: 2.299 ms Execution Time: 198.809 ms (9 rows) Here about 15.8% of the time is spent waiting for IO, improved by prefetching only to 14.4%. 1M rows: prefetching=0 Index Scan using idx_periodic_1000000 on prefetch_test_data_1000000 (cost=0.42..153478.15 rows=1000000 width=8) (actual time=0.126..5172.605 rows=1000000.00 loops=1) Index Searches: 1 Buffers: shared hit=971485 read=31250 I/O Timings: shared read=3371.993 Planning: Buffers: shared hit=96 read=7 I/O Timings: shared read=0.591 Planning Time: 0.946 ms Execution Time: 5225.337 ms prefetching=1: Index Scan using idx_periodic_1000000 on prefetch_test_data_1000000 (cost=0.42..153478.15 rows=1000000 width=8) (actual time=0.126..2106.244 rows=1000000.00 loops=1) Index Searches: 1 Buffers: shared hit=971485 read=31250 I/O Timings: shared read=94.310 Planning: Buffers: shared hit=96 read=7 I/O Timings: shared read=0.585 Planning Time: 0.938 ms Execution Time: 2157.727 ms Here about 64.5% of the time is spent waiting for IO, improved by prefetching to 4.3%. I think one reason the smaller data performs so badly is that read stream ramps down the distance too quickly, due to the high cache hit ratio, at least in the periodic case. If I disable the stream->distance-- in read_stream.c, the results, particularly with debug_io_direct=data, are vastly better ([1]). It's easier to see with DIO: debug_io_direct=data, enable_indexscan_prefetch=0 ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ QUERY PLAN │ ├──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ Index Scan using idx_periodic_100000 on prefetch_test_data_100000 (cost=0.29..15351.09 rows=100000 width=8) (actual time=0.311..643.697 rows=100000.00 loops=1) │ │ Index Searches: 1 │ │ Buffers: shared hit=97150 read=3125 │ │ I/O Timings: shared read=479.851 │ │ Planning Time: 0.066 ms │ │ Execution Time: 648.820 ms │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ (6 rows) debug_io_direct=data, enable_indexscan_prefetch=1, w/ distance-- ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ QUERY PLAN │ ├──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ Index Scan using idx_periodic_100000 on prefetch_test_data_100000 (cost=0.29..15351.09 rows=100000 width=8) (actual time=0.570..676.908 rows=100000.00 loops=1) │ │ Index Searches: 1 │ │ Prefetch: distance=2.000 count=6008 stalls=93627 skipped=0 resets=0 pauses=0 ungets=0 forwarded=0 │ │ histogram [2,4) => 6008 │ │ Buffers: shared hit=97150 read=3125 │ │ I/O Timings: shared read=507.223 │ │ Planning Time: 0.056 ms │ │ Execution Time: 682.205 ms │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ debug_io_direct=data, enable_indexscan_prefetch=1, w/o distance-- ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ QUERY PLAN │ ├──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ Index Scan using idx_periodic_100000 on prefetch_test_data_100000 (cost=0.29..15351.09 rows=100000 width=8) (actual time=0.304..187.170 rows=100000.00 loops=1) │ │ Index Searches: 1 │ │ Prefetch: distance=750.741 count=99721 stalls=4 skipped=0 resets=0 pauses=90 ungets=0 forwarded=0 │ │ histogram [2,4) => 3, [4,8) => 4, [8,16) => 6, [16,32) => 10, [32,64) => 25, [64,128) => 33, [128,256) => 65, [256,512) => 130, [512,1024) => 99445 │ │ Buffers: shared hit=97150 read=3125 │ │ I/O Timings: shared read=25.086 │ │ Planning Time: 0.062 ms │ │ Execution Time: 192.363 ms │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ If the distance ends up capped at 2, it's not too surprising that readahead doesn't work out. FWIW, all that's seemingly needed to actually have mostly sufficient distance is to change the distance increase from distance = stream->distance * 2; to distance = stream->distance * 2 + 1; The + 1 has a big effect because when the distance is 1, each hit reduces the distance by as much as each miss does. Just addressing that improves the results dramatically: debug_io_direct=data, enable_indexscan_prefetch=1, w/ stream->distance * 2 + 1 ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ QUERY PLAN │ ├─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ Index Scan using idx_periodic_100000 on prefetch_test_data_100000 (cost=0.29..15351.09 rows=100000 width=8) (actual time=0.316..176.703 rows=100000.00 loops=1) │ │ Index Searches: 1 │ │ Prefetch: distance=707.476 count=11158 stalls=88503 skipped=0 resets=0 pauses=26 ungets=0 forwarded=0 │ │ histogram [2,4) => 5, [4,8) => 11, [8,16) => 26, [16,32) => 30, [32,64) => 54, [64,128) => 109, [128,256) => 221, [256,512) => 428, [512,1024) => 10274 │ │ Buffers: shared hit=96875 read=3400 │ │ I/O Timings: shared read=33.874 │ │ Planning: │ │ Buffers: shared hit=78 read=21 │ │ I/O Timings: shared read=2.772 │ │ Planning Time: 3.065 ms │ │ Execution Time: 182.959 ms │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ The stall stats are bogus, because they get increased even when we correctly are not prefetching due to everything being in shared buffers. I think the if (distance == 1) stats.nstalls++ would need to be just before the WaitReadBuffers(). Interestingly the stream->distance * 2 + 1 performs considerably better than never decreasing the distance for the periodic case, which I guess makes sense, because once the data is in s_b, it is purely cost to have a high distance (for now, eventually I hope we can do batched buffer lookups to have a small gain even in that case). Greetings, Andres Freund [1] That's of course not an actual proposal, just a test
Commits
-
read stream: Split decision about look ahead for AIO and combining
- 8ca147d582a5 19 (unreleased) landed
-
read_stream: Only increase read-ahead distance when waiting for IO
- f63ca3379025 19 (unreleased) landed
-
aio: io_uring: Trigger async processing for large IOs
- a9ee66881744 19 (unreleased) landed
-
heapam: Keep buffer pins across index scan resets.
- 2d3490dd99f0 19 (unreleased) landed
-
heapam: Track heap block in IndexFetchHeapData.
- c7d09595e46f 19 (unreleased) landed
-
Move heapam_handler.c index scan code to new file.
- a29fdd6c8d81 19 (unreleased) landed
-
Rename heapam_index_fetch_tuple argument for clarity.
- 1adff1a0c558 19 (unreleased) landed
-
Optimize fast-path FK checks with batched index probes
- b7b27eb41a5c 19 (unreleased) cited
-
read_stream: Prevent distance from decaying too quickly
- 6e36930f9aaf 19 (unreleased) landed
-
read_stream: Issue IO synchronously while in fast path
- cceb1bf45e3a 19 (unreleased) landed
-
bufmgr: Return whether WaitReadBuffers() needed to wait
- 513374a47a71 19 (unreleased) landed
-
aio: io_uring: Allow IO methods to check if IO completed in the background
- 6e648e353fa0 19 (unreleased) landed
-
bufmgr: Make UnlockReleaseBuffer() more efficient
- f39cb8c01106 19 (unreleased) cited
-
Add fake LSN support to hash index AM.
- e5836f7b7d9a 19 (unreleased) landed
-
Make IndexScanInstrumentation a pointer in executor scan nodes.
- f026fbf059f2 19 (unreleased) landed
-
Use fake LSNs to improve nbtree dropPin behavior.
- 8a879119a1d1 19 (unreleased) landed
-
Move fake LSN infrastructure out of GiST.
- d774072f0040 19 (unreleased) landed
-
Use simplehash for backend-private buffer pin refcounts.
- a367c433ad01 19 (unreleased) landed
-
nbtree: Avoid allocating _bt_search stack.
- d071e1cfec23 19 (unreleased) landed
-
bufmgr: Fix use of wrong variable in GetPrivateRefCountEntrySlow()
- 6322a028fa43 19 (unreleased) landed
-
Conditional locking in pgaio_worker_submit_internal
- 29a0fb215779 19 (unreleased) landed
-
Reduce ExecSeqScan* code size using pg_assume()
- b227b0bb4e03 19 (unreleased) cited
-
Fix rare bug in read_stream.c's split IO handling.
- b421223172a2 19 (unreleased) cited
-
Remove HeapBitmapScan's skip_fetch optimization
- 459e7bf8e2f8 18.0 cited
-
Optimize nbtree backwards scans.
- 1bd4bc85cac2 18.0 cited
-
Fix multiranges to behave more like dependent types.
- 3e8235ba4f9c 17.0 cited
-
Add EXPLAIN (MEMORY) to report planner memory consumption
- 5de890e3610d 17.0 cited
-
Optimize nbtree backward scan boundary cases.
- c9c0589fda0e 17.0 cited
-
Increment xactCompletionCount during subtransaction abort.
- 90c885cdab8b 14.0 cited
-
Add nbtree Valgrind buffer lock checks.
- 4a70f829d86c 14.0 cited
-
Add nbtree high key "continuescan" optimization.
- 29b64d1de7c7 12.0 cited
-
Reduce pinning and buffer content locking for btree scans.
- 2ed5b87f96d4 9.5.0 cited
-
Teach btree to handle ScalarArrayOpExpr quals natively.
- 9e8da0f75731 9.2.0 cited