Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s7429-003P0a-EP for pgsql-hackers@arkaria.postgresql.org; Wed, 15 May 2024 02:06:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s7429-006jmT-Dj for pgsql-hackers@arkaria.postgresql.org; Wed, 15 May 2024 02:06:21 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s7429-006jmL-41 for pgsql-hackers@lists.postgresql.org; Wed, 15 May 2024 02:06:21 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s7426-000G5Z-EB for pgsql-hackers@postgresql.org; Wed, 15 May 2024 02:06:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2024011501; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description; bh=6AU/ltUY2C+bn65NoMpHC08MBZHBuAUvfMhjcNF1ry4=; b=bQneP dsJP0OpazWy5SYsJZ60kOZRQswCPxi4V4IzQUUttRArSoQZzttFHNJSCfpltj2J7yjOWqXXPmXMIS r1SE5+f7PHI95kIhfBm9Qqt2aAtMMdGD7JSQ2TmQnn384B0IKSnXW+yQS9H6v2FHPFNVjXxkWi5Re k8JazocSaeofBxNyRbU1QR85LZugiLRfDP7MwCLqymROhlxFxbM38quiP0lvXyX5ZCg8XI8fNTRep C3FSnDcPvMGgkCC9ihyckm6fKf4yGa1aqYi/59OarO5qOp7rl+hDnfx+LJ2jjmJDtm5NoUNhb2XiM 4fpfhqQRU0XTOpJePZA295f41TCqQ==; Received: from bruce by momjian.us with local (Exim 4.96) (envelope-from ) id 1s7425-008lVG-06; Tue, 14 May 2024 22:06:17 -0400 Date: Tue, 14 May 2024 22:06:17 -0400 From: Bruce Momjian To: David Rowley Cc: Melanie Plageman , PostgreSQL-development Subject: Re: First draft of PG 17 release notes Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, May 15, 2024 at 02:03:32PM +1200, David Rowley wrote: > On Wed, 15 May 2024 at 13:00, Bruce Momjian 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? -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.