Re: aio/README.md comments - Mailing list pgsql-hackers

From Andres Freund
Subject Re: aio/README.md comments
Date
Msg-id o45s4wphhpzyfljhs3yyx3j2rveckngz6szesageacbrdhyqkc@sek5sfzn6aea
Whole thread Raw
In response to aio/README.md comments  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: aio/README.md comments
List pgsql-hackers
Hi,

On 2025-08-29 08:12:36 -0700, Jeff Davis wrote:
> aio/README.md:
>
> * In the section "### IO can be started in critical sections", the
> first paragraph seems like it belongs in another section.

It explains why we want to eventually want do WAL IO using AIO, which in turn
requires AIO to be executable in critical section. So it's intentionally there
and I think has to be there in some form - if you have suggestion for how to
make that clearer...


> * The README generally mixes design goals with implemented
> functionality. For instance, we're only using it on the read path
> currently, but the README mentions WAL writing several times. We should
> probably clarify that a bit.

It mentions WAL writes because they have a huge design impact... What
concretely would you like to clarify?


> * "`io_method=sync` does not actually perform AIO but allows to use the
> AIO API while performing synchronous IO. This can be useful for
> debugging." Sync is still useful for cases where the shared buffers are
> a small fraction of system memory, right?

I don't really see an advantage of sync in those cases either. IO latency can
be really painful if s_b is a small fraction of memory too, and it can be
avoided by doing real readahead.


> * "Particularly on modern storage..." I assume this is talking about
> SSDs, but it could also mean some kind of network block storage.

As the start of the bullet point says, it's about high throughput
storage. Yes, that most crucially is indeed PCIe connected SSDs, but you can
have pretty darn fast networked storage too. Once you do > 1GB/s of IO, the
cycles for actually copying memory become really relevant.


> If our architecture is changing in response to new real-world hardware, we
> should briefly try to connect the design choices to assumptions about
> hardware, where appropriate.

Could you make a bit of a more concrete suggestion of what you would like to
see mentioned? I tried to keep it a bit technology neutral, because mentioning
specific technologies tends to get more out of date than more general things
like storage that has high throughput - I don't think we'll go back to SATA
devices with ~600MB/s of hard bus limited throughput...


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Assert single row returning SQL-standard functions
Next
From: Ranier Vilela
Date:
Subject: Re: Avoid overwiriting cache entry (src/backend/utils/cache/relcache.c)