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 1s7GKj-004e7w-QF for pgsql-hackers@arkaria.postgresql.org; Wed, 15 May 2024 15:14:23 +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 1s7GKj-000n6l-Tb for pgsql-hackers@arkaria.postgresql.org; Wed, 15 May 2024 15:14: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 1s7GKj-000n6c-Ha for pgsql-hackers@lists.postgresql.org; Wed, 15 May 2024 15:14:21 +0000 Received: from fout2-smtp.messagingengine.com ([103.168.172.145]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s7GKg-000LjY-Ut for pgsql-hackers@postgresql.org; Wed, 15 May 2024 15:14:20 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id 846B01380170; Wed, 15 May 2024 11:14:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 15 May 2024 11:14:17 -0400 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 :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1715786057; x= 1715872457; bh=XyisvQaPqYfaiMDyxg36DrgBZGzUXKgbNaGKwrLCUQo=; b=K uTsVUhOYh6k2p43QSpnJFJ5Xo4Uf6Tyj8WoRba9U62Q6SIF8cZqbjQwr5PyGxUJ9 jqEOPN3sw5PPo9pNj5aMkrw4UycSecCyqE4mliINeRm2GuouEqnGsR9XMfR8+ZkY diYGjCAEKtD7IoTTCgpH1yV0D9hNe9dmY5Jno3Gjtw6f5JNab2P8+7zpBfnUDwRK ZZISChag4xJJem96W4WiS0zsHSNfgO2G/b3Q0nCZNamedPDrBZ2I5Dd30kSbM3j+ 386A+OutBVF2zVFbVxe5roVjLdAHXQalXRsBqAopaaU199XRFmB/BMUwf3aaN2WG VWzokcK3ElVA88JelgdFA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdegkedgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepvdektdffudfftdffffehfffhjeejhffgieeuueekjeek fffgudffhfduffffueevnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 15 May 2024 11:14:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1715786055; bh=lcGpYr3jIHKVLp+JE+CnrUzEQgSsm0OO82+r5dX/6S4=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=hLAo0fmKdcJJ0chGwM7yUvTt33wk2w5cQiiI5825zdjJcs03j4S2NCJs9EN9rhIt0 vaWRxqbMfayHwouv3xMRaPqb6g+x/jCRGhzZYGRWttAIs7hpQrquAfnWKqDunu22g6 J1k3/1mIt6ACgeYO+mHtALX4yga6PZJ3+Yv+ef7efd8oSgmnj+hXNTKpCPikpbGGy/ KeUogh+A2E+6x3cQi89sWRbUKiuLlGk8ztmutmY9buPOin2RH/GqXwb8I0tluBj9Cr JbY6vxViBY/8HNVz7tade8Ogyd0zOdRmqMm+UOiCWJhWtgrNspKa3sjXqt1oJyVSVq SwI3ghTB8ha2g== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id 0C9C210B; Wed, 15 May 2024 17:14:15 +0200 (CEST) Date: Wed, 15 May 2024 17:14:15 +0200 From: Alvaro Herrera To: Melanie Plageman Cc: Tomas Vondra , Michael Paquier , Thomas Munro , Heikki Linnakangas , Andres Freund , Pg Hackers , Nazir Bilal Yavuz Subject: Re: BitmapHeapScan streaming read user and prelim refactoring Message-ID: <202405151514.owoztajhysog@alvherre.pgsql> 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 On 2024-May-14, Melanie Plageman wrote: > On Tue, May 14, 2024 at 4:05 PM Alvaro Herrera wrote: > > I do wonder how do we _know_ that the test is testing what it wants to > > test: > We include the explain output (the plan) to ensure it is still > using a bitmap heap scan. The test exercises the skip fetch > optimization in bitmap heap scan when not all of the inner tuples are > emitted. I meant -- the query returns an empty resultset, so how do we know it's the empty resultset that we want and not a different empty resultset that happens to be identical? (This is probably not a critical point anyhow.) > Without the patch, the test fails, so it is protection against someone > adding back that assert in the future. It is not protection against > someone deleting the line > scan->rs_empty_tuples_pending = 0 > That is, it doesn't verify that the empty unused tuples count is > discarded. Do you think that is necessary? I don't think that's absolutely necessary. I suspect there are thousands of lines that you could delete that would break things, with no test directly raising red flags. At this point I would go with the RMT's recommendation of pushing this now to make sure the bug is fixed for beta1, even if the test is imperfect. You can always polish the test afterwards if you feel like it ... -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "No necesitamos banderas No reconocemos fronteras" (Jorge González)