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