Hi,
On 2025-08-15 12:24:40 -0400, Peter Geoghegan wrote:
> With bufmgr patch
> -----------------
>
> ┌─────────────────────────────────────────────────────────────┐
> │ QUERY PLAN │
> ├─────────────────────────────────────────────────────────────┤
> │ Index Scan using t_pk on t (actual rows=1048576.00 loops=1) │
> │ Index Cond: ((a >= 16336) AND (a <= 49103)) │
> │ Index Searches: 1 │
> │ Buffers: shared hit=10257 read=49933 │
> │ I/O Timings: shared read=135.825 │
> │ Planning: │
> │ Buffers: shared hit=50 read=6 │
> │ I/O Timings: shared read=0.570 │
> │ Planning Time: 0.767 ms │
> │ Execution Time: 279.643 ms │
> └─────────────────────────────────────────────────────────────┘
> (10 rows)
>
> I _think_ that Andres' patch also fixes the EXPLAIN ANALYZE accounting, so
> that "I/O Timings" is actually correct. That's why EXPLAIN ANALYZE with the
> bufmgr patch has much higher "shared read" time, despite overall execution
> time being cut in half.
Somewhat random note about I/O waits:
Unfortunately the I/O wait time we measure often massively *over* estimate the
actual I/O time. If I execute the above query with the patch applied, we
actually barely ever wait for I/O to complete, it's all completed by the time
we have to wait for the I/O. What we are measuring is the CPU cost of
*initiating* the I/O.
That's why we are seeing "I/O Timings" > 0 even if we do perfect readahead.
Most of the cost is in the kernel, primarily looking up block locations and
setting up the actual I/O.
Greetings,
Andres Freund
