Horton

Re: AIO / read stream heuristics adjustments for index prefetching

Melanie Plageman <melanieplageman@gmail.com>

View thread View on postgr.es
From: Melanie Plageman <melanieplageman@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Tomas Vondra <tv@fuzzy.cz>, Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: 2026-04-01T14:52:03Z
Lists: pgsql-hackers 
On Tue, Mar 31, 2026 at 12:02 PM Andres Freund <andres@anarazel.de> wrote:
>
> 0008: WIP: read stream: Split decision about look ahead for AIO and combining
>
>     Until now read stream has used a single look-ahead distance to control
>     lookahead for both IO combining and read-ahead. That's sub-optimal, as we
>     want to do IO combining even when we don't need to do any readahead, as
>     avoiding the syscall overhead is important to reduce CPU overhead when
>     data is in the kernel page cache.
>
>     This is a prototype for what it could look like to split those
>     decisions. Thereby fixing the regression mentioned in 0006.

I wonder if we need to keep the combine_limit member in the read
stream. Could we just use io_combine_limit without ramping up and
down? This is mainly for code complexity reasons. Perhaps to allow
fast path reentry, we could use distance_decay_holdoff == 0 and
ios_in_progress == 0 instead of combine_distance == 0.

- Melanie

Commits

  1. aio: io_uring: Trigger async processing for large IOs

  2. read stream: Split decision about look ahead for AIO and combining

  3. read_stream: Move logic about IO combining & issuing to helpers

  4. read_stream: Only increase read-ahead distance when waiting for IO

  5. read_stream: Prevent distance from decaying too quickly

  6. read_stream: Issue IO synchronously while in fast path

  7. aio: io_uring: Allow IO methods to check if IO completed in the background

  8. bufmgr: Return whether WaitReadBuffers() needed to wait