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.96) (envelope-from ) id 1w8PcC-000VVH-2d for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2026 21:30:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w8PcB-008Aii-22 for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2026 21:30:12 +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.96) (envelope-from ) id 1w8PcB-008Aia-19 for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2026 21:30:11 +0000 Received: from fout-b5-smtp.messagingengine.com ([202.12.124.148]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w8Pc9-00000000FTI-3827 for pgsql-hackers@postgresql.org; Thu, 02 Apr 2026 21:30:10 +0000 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id 4FF091D00163; Thu, 2 Apr 2026 17:30:08 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Thu, 02 Apr 2026 17:30:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1775165408; x=1775251808; bh=4tIOwlN6mjGORpyIWVDZIhQEGP/La0hpihUDOetEDPQ=; b= RcrsV/8AxTmlP7eAnsgZX4rhpT0r0/yEopoV4wlaG2eWqcayCoJgSgMiZls5FtxK kXbd6SD5gph68vqRyPOI/8Kq0ylq+m35iGybnAl/6mgXSyFGW0BrRgwXI22cAh62 cHbPFdJ4Rsx6EN0Unm3hQuxVdutDdCvD0in5CICRlJRybJFwQOdOXlh2MZ1KY/aQ OPmMTw9AFeO1WnH1lrdVpYz+3plfAha6XwLfkAnQu7VIMIcTrVRjrbG/wsK4sB+g SOYl8tThEOaK9gi5drO7M1V00EaFFZ7DMgACQLDzqGE58Rw44kAy3c/QQzjpDynS sLHeZ/PVvEtm4DYo2jWm1g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1775165408; x= 1775251808; bh=4tIOwlN6mjGORpyIWVDZIhQEGP/La0hpihUDOetEDPQ=; b=o Xe01n5NYJByEEMb6ac2pHkF1BzV7pfOL5GinvaUs4YJ999TGFgmaHYQYWs0nMAvm zxINcB2lMYeKexih1nr2luup/oAx3slmCgLx92frdqC4WDg282X89M07EwV1l0Dh LTjzW5R10wMjIJhHw5bNToW/18lVzbTHh85MhD6NbfH7zvcBUVkqL4eL4UKCkJh0 2mfvleGs39zX9SgDXP1hVyA6SdatDgTLQQN/KkvtsK9nqrwGBrhDYC7sL4E9UzhL vz+6DvFAIW3CxTIBUXJ08GEn1EU5D61lbca9TYSAOU7hAPDp4/TB8jTHtzsFMJb4 o1oSOTZlyJcUk9QgTfiYQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdejudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epfffhvfevuffkfhggtggugfgjsehtkefstddttdejnecuhfhrohhmpeetnhgurhgvshcu hfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucggtffrrghtth gvrhhnpedtleelvdfgjedvffeiueekfeeuleffhfegfffhgfffkeevueehieehhfeigffh vdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnh gurhgvshesrghnrghrrgiivghlrdguvgdpnhgspghrtghpthhtohepiedpmhhouggvpehs mhhtphhouhhtpdhrtghpthhtohepphhgsegsohifthdrihgvpdhrtghpthhtohepthhvse hfuhiiiiihrdgtiidprhgtphhtthhopegshigrvhhuiiekudesghhmrghilhdrtghomhdp rhgtphhtthhopehmvghlrghnihgvphhlrghgvghmrghnsehgmhgrihhlrdgtohhmpdhrtg hpthhtohepthhhohhmrghsrdhmuhhnrhhosehgmhgrihhlrdgtohhmpdhrtghpthhtohep phhgshhqlhdqhhgrtghkvghrshesphhoshhtghhrvghsqhhlrdhorhhg X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 2 Apr 2026 17:30:06 -0400 (EDT) Date: Thu, 2 Apr 2026 17:30:05 -0400 From: Andres Freund To: Melanie Plageman Cc: pgsql-hackers@postgresql.org, Thomas Munro , Peter Geoghegan , Tomas Vondra , Nazir Bilal Yavuz Subject: Re: AIO / read stream heuristics adjustments for index prefetching Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2026-04-02 17:13:34 -0400, Melanie Plageman wrote: > On Thu, Apr 2, 2026 at 11:47 AM Andres Freund wrote: > > > > > On some level, relying on worker mode overhead feels fragile. If > > > worker overhead decreases—say, by moving to IO worker threads—we won't > > > be able to rely on this to keep the distance to an advantageous level. > > > > I don't see why lower overhead would prevent this from working? > > needed_wait has to be true to increase the readahead distance and for > io_uring, when data was in the kernel buffer cache, needed_wait is > false, meaning the distance doesn't increase. Worker mode didn't have > this problem because of overhead. So needed_wait is true for workers. > But, now that we will have combine_distance, I guess we don't need to > rely on workers having overhead. I think we still do, but that it will continue to work, even if the overhead is much smaller than today. The workers will complete the IOs only after the memory copy is finished (duh). Therefore, if the distance is too small to allow workers to complete the copy, the distance will be increased, due to needed_wait. > So we are saying that readahead_distance is completely irrelevant for > copying from the kernel buffer cache and only combine_distance matters for > that now, right? I don't think so! The combine_distance thing is crucial to allow for IO combining, and, indirectly, for triggering the size based "async" heuristics with io_uring. Once the io_uring async heuristic is triggered, the needed_wait mechanism works to further increase the distance. That does mean that for random BLCKSZ sized IOs that are in the page cache the async mechanism won't typically be triggered - but from what I can tell that's ok, because lots of 8kB IOs is also where the dispatch overhead to the kernel threads doing the copying is the highest. Greetings, Andres Freund