Re: aio/README.md comments
От | Andres Freund |
---|---|
Тема | Re: aio/README.md comments |
Дата | |
Msg-id | o45s4wphhpzyfljhs3yyx3j2rveckngz6szesageacbrdhyqkc@sek5sfzn6aea обсуждение исходный текст |
Ответ на | aio/README.md comments (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: aio/README.md comments
|
Список | 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 по дате отправления: