On Thu, May 29, 2025 at 09:42:30AM -0400, Melanie Plageman wrote: > > > "Add an asynchronous I/O subsystem" > > > > > > I notice we don't call out any of the operations where users could > > > expect to see asynchronous IO be used. Some were enabled in 17 (like > > > sequential scans, analyze, and pg_prewarm), but most of the read > > > stream users went in this release: > > > > > > d9c7911e1a5, 043799fa08c, e215166c9c8, 69273b818b1, c5c239e26e3, > > > 2b73a8cd33b, 9256822608f, c3e775e608f, 8720a15e9ab12, 65c310b310a > > > > > > I have had users ask me already which operations they can expect to > > > use asynchronous I/O. The most commonly encountered AIO operations are > > > probably be vacuum, bitmap heap scan, and sequential scans, but it > > > might be worth having a list somewhere of what uses AIO. I expect > > > we'll get the question quite often. > > > > Yes, I knew I needed more detail on this. I have added text in this > > commit to try to improve that. > > Maybe it is worth saying something at the end like "amongst other > operations" to clarify it isn't just those.
I am not a fan of "etc." but in this case it makes sense, so added it in the attached, applied patch. > I noticed in the PG 17 release notes [1] we did include the shas of > each of the commits for the read stream users. Should we do that here > as well? Those are what enable those operations to use AIO. So, I added the read stream item to PG 17 since that was a new infrastructure feature, but for PG 18, we are just improving that internal infrastructure, so didn't mention it. If you think we should add those commits, I can do it. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml index 718f7b20bf1..3315ea52def 100644 --- a/doc/src/sgml/release-18.sgml +++ b/doc/src/sgml/release-18.sgml @@ -569,7 +569,7 @@ Add an asynchronous I/O subsystem (Andres Freund, Thomas Munro, Nazir Bilal Yavu </para> <para> -This feature allows backends to queue multiple read requests, which allows for more efficient sequential scans, bitmap heap scans, and vacuums. +This feature allows backends to queue multiple read requests, which allows for more efficient sequential scans, bitmap heap scans, vacuums, etc. This is enabled by server variable io_method, with server variables io_combine_limit and io_max_combine_limit added to control it. This also enables effective_io_concurrency and maintenance_io_concurrency values greater than zero for systems without fadvise() support. The new system view pg_aios shows the file handles being used for asynchronous I/O.
