On Wed, May 15, 2024 at 7:36 AM Bruce Momjian <br...@momjian.us> wrote: > > On Wed, May 15, 2024 at 02:03:32PM +1200, David Rowley wrote: > > On Wed, 15 May 2024 at 13:00, Bruce Momjian <br...@momjian.us> wrote: > > > > > > On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote: > > > > "Reduce system calls by automatically merging reads up to > > > > io_combine_limit" > > > > > > Uh, as I understand it, the reduced number of system calls is not the > > > value of the feature, but rather the ability to request a larger block > > > from the I/O subsystem. Without it, you have to make a request and wait > > > for each request to finish. I am open to new wording, but I am not sure > > > your new wording is accurate. > > > > I think you have the cause and effect backwards. There's no advantage > > to reading 128KB if you only need 8KB. It's the fact that doing > > *larger* reads allows *fewer* reads that allows it to be more > > efficient. There are also the efficiency gains from fadvise > > POSIX_FADV_WILLNEED. I'm unsure how to jam that into a short sentence. > > Maybe; "Optimize reading of tables by allowing pages to be prefetched > > and read in chunks up to io_combine_limit", or a bit more buzzy; > > "Optimize reading of tables by allowing pages to be prefetched and > > performing vectored reads in chunks up to io_combine_limit". > > Yes, my point is that it is not the number of system calls or system > call overhead that is the advantage of this patch, but the ability to > request more of the I/O system in one call, which is not the same as > system calls. > > I can use your wording, but how much prefetching to we enable now? >
Shouldn't we need to include commit b5a9b18cd0bc6f0124664999b31a00a264d16913 with this item? -- With Regards, Amit Kapila.