| 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
| 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 |