Re: AIO / read stream heuristics adjustments for index prefetching

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Tomas Vondra <tv(at)fuzzy(dot)cz>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
Subject: Re: AIO / read stream heuristics adjustments for index prefetching
Date: 2026-04-01 14:52:03
Message-ID: CAAKRu_aG2zvObX6gQ3Kw=MPydbphZ-qKeMGwZDEFe55FFiXYWw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 31, 2026 at 12:02 PM Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-04-01 14:54:23 Re: DOCS - DROP SUBSCRIPTION does not document parameter "IF EXISTS"
Previous Message Andres Freund 2026-04-01 14:49:28 Re: 'Bad file descriptor: dup2( 1, 2 )' error on MacOS CI tasks