Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q9ZVy-0003AC-Q0 for pgsql-bugs@arkaria.postgresql.org; Wed, 14 Jun 2023 23:02:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q9ZVx-0003Ql-NZ for pgsql-bugs@arkaria.postgresql.org; Wed, 14 Jun 2023 23:02:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q9ZVx-0003Qc-Fa for pgsql-bugs@lists.postgresql.org; Wed, 14 Jun 2023 23:02:57 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q9ZVv-002Pyo-1H for pgsql-bugs@lists.postgresql.org; Wed, 14 Jun 2023 23:02:56 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 35EN2mBS2020236; Wed, 14 Jun 2023 19:02:48 -0400 From: Tom Lane To: Andres Freund cc: tel@jklm.no, pgsql-bugs@lists.postgresql.org, David Rowley , Peter Geoghegan Subject: Re: BUG #17975: Nested Loop Index Scan returning wrong result In-reply-to: <20230614224928.l255k2okc3ms3iph@awork3.anarazel.de> References: <17975-98a90c156f25c952@postgresql.org> <20230614203651.hyc4cjdzhgrg3pav@awork3.anarazel.de> <20230614211231.pudg2y2rz6az2vij@awork3.anarazel.de> <20230614224928.l255k2okc3ms3iph@awork3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Wed, 14 Jun 2023 15:49:28 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2020234.1686783768.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Jun 2023 19:02:48 -0400 Message-ID: <2020235.1686783768@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: > On 2023-06-14 14:12:31 -0700, Andres Freund wrote: >> We either need to force the index that we got the uniqueness informatio= n to be >> used when it is partial, or add the quals from the partial unique index= to all >> other index scans. I did not study this example yet, but generally we ignore predicate indexes unless their predicates can be proven from base restrictions of their table (that's what predOK means). If the base restrictions are enforced at scan level, which they should be, then uniqueness should hold at any join level regardless of whether we actually scanned with that index or some other way. Maybe we broke that chain of reasoning somehow? > It's not immediately obvious to me how to nicely fix this in a backpatch= able > way. An easy fix would be to not allow predicate indexes at all anymore = in > relation_has_unique_index_for(), but that's a pretty big cannon - fixes = the > issue though. Yeah, that would be the easy way out if we don't find a better answer. But right at the moment I don't understand why this is failing. regards, tom lane