MIME-Version: 1.0
References: <f3xxfrkafjxpyqxywcxricxgyizjirfceychyxsgn7bwjp5eda@kwbduhy7tfmu>
In-Reply-To: <f3xxfrkafjxpyqxywcxricxgyizjirfceychyxsgn7bwjp5eda@kwbduhy7tfmu>
From: Melanie Plageman <melanieplageman@gmail.com>
Date: Wed, 1 Apr 2026 10:52:03 -0400
Message-ID: 
 <CAAKRu_aG2zvObX6gQ3Kw=MPydbphZ-qKeMGwZDEFe55FFiXYWw@mail.gmail.com>
Subject: Re: AIO / read stream heuristics adjustments for index prefetching
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAAKRu_aG2zvObX6gQ3Kw%3DMPydbphZ-qKeMGwZDEFe55FFiXYWw%40mail.gmail.com>
Precedence: bulk

On Tue, Mar 31, 2026 at 12:02=E2=80=AFPM Andres Freund <andres@anarazel.de>=
 wrote:
>
> 0008: WIP: read stream: Split decision about look ahead for AIO and combi=
ning
>
>     Until now read stream has used a single look-ahead distance to contro=
l
>     lookahead for both IO combining and read-ahead. That's sub-optimal, a=
s 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 whe=
n
>     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 =3D=3D 0 and
ios_in_progress =3D=3D 0 instead of combine_distance =3D=3D 0.

- Melanie