Re: AIO v2.0

From: Noah Misch <noah(at)leadboat(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, 陈宗志 <baotiao(at)gmail(dot)com>
Subject: Re: AIO v2.0
Date: 2024-09-30 19:29:53
Message-ID: 20240930192953.19.nmisch@google.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 30, 2024 at 10:49:17AM -0400, Andres Freund wrote:
> We also discussed the topic at https://postgr.es/m/20240925020022.c5.nmisch%40google.com
> > ... neither BM_SETTING_HINTS nor keeping bounce buffers looks like a bad
> > decision. From what I've heard so far of the performance effects, if it were
> > me, I would keep the bounce buffers. I'd pursue BM_SETTING_HINTS and bounce
> > buffer removal as a distinct project after the main AIO capability. Bounce
> > buffers have an implementation. They aren't harming other design decisions.
> > The AIO project is big, so I'd want to err on the side of not designating
> > other projects as its prerequisites.
>
> Given the issues that modifying pages while in flight causes, not just with PG
> level checksums, but also filesystem level checksum, I don't feel like it's a
> particularly promising approach.
>
> However, I think this doesn't have to mean that the BM_SETTING_HINTS stuff has
> to be completed before we can move forward with AIO. If I split out the write
> portion from the read portion a bit further, the main AIO changes and the
> shared-buffer read user can be merged before there's a dependency on the hint
> bit stuff being done.
>
> Does that seem reasonable?

Yes.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2024-09-30 19:33:50 Re: Inval reliability, especially for inplace updates
Previous Message Tom Lane 2024-09-30 19:24:26 Re: SET or STRICT modifiers on function affect planner row estimates