Hi, On 2025-02-09 21:06:02 +0100, Jelte Fennema-Nio wrote: > On Sun, 9 Feb 2025 at 19:05, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > Andres Freund <and...@anarazel.de> writes: > > > I'm somewhat against this patch, as it's fairly fundamentally incompatible > > > with AIO. There's no real way to get information in this manner if the IO > > > isn't executed synchronously in process context... > > Hmm, I had not considered how this would interact with your AIO work. > I agree that getting this info would be hard/impossible to do > efficiently, when IOs are done by background IO processes that > interleave IOs from different queries. But I'd expect that AIOs that > are done using iouring would be tracked correctly without having to > change this code at all (because I assume those are done from the > query backend process). > > One other thought: I think the primary benefit of this feature is > being able to see how many read IOs actually hit the disk, as opposed > to hitting OS page cache. That benefit disappears when using Direct > IO, because then there's no OS page cache. > > How many years away do you think that widespread general use of > AIO+Direct IO is, though?
I think it'll always be a subset of use. It doesn't make sense to use DIO for a small databases or untuned databases. Or a system that's deliberately overcommmitted. But this will also not work with AIO w/ Buffered IO. Which we hope to use much more commonly. If suddenly I have to reimplement something like this to work with worker based IO, it'll certainly take longer to get to AIO. Greetings, Andres Freund