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 1q9aqk-0006Si-RJ for pgsql-bugs@arkaria.postgresql.org; Thu, 15 Jun 2023 00:28:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q9aqj-0004IV-Ae for pgsql-bugs@arkaria.postgresql.org; Thu, 15 Jun 2023 00:28:29 +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 1q9aqj-0004IM-2w for pgsql-bugs@lists.postgresql.org; Thu, 15 Jun 2023 00:28:29 +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 1q9aqg-002Qhg-EQ for pgsql-bugs@lists.postgresql.org; Thu, 15 Jun 2023 00:28:28 +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 35F0SKkO2029338; Wed, 14 Jun 2023 20:28:20 -0400 From: Tom Lane To: David Rowley cc: Andres Freund , tel@jklm.no, pgsql-bugs@lists.postgresql.org, Peter Geoghegan Subject: Re: BUG #17975: Nested Loop Index Scan returning wrong result In-reply-to: References: <17975-98a90c156f25c952@postgresql.org> <20230614203651.hyc4cjdzhgrg3pav@awork3.anarazel.de> <20230614211231.pudg2y2rz6az2vij@awork3.anarazel.de> <20230614224928.l255k2okc3ms3iph@awork3.anarazel.de> <2020235.1686783768@sss.pgh.pa.us> <20230614235711.x2ffx54zi7mnt6ho@awork3.anarazel.de> <2026451.1686787166@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Thu, 15 Jun 2023 12:16:54 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2029336.1686788900.1@sss.pgh.pa.us> Date: Wed, 14 Jun 2023 20:28:20 -0400 Message-ID: <2029337.1686788900@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > On Thu, 15 Jun 2023 at 11:59, Tom Lane wrote: >> But how did it decide that the partial index is predOK, if there's not >> a qual forcing a_id to not be null? > In this case a.id = b.a_id AND c.id = b.c_id are used as proofs. I > didn't debug all the way, but I assume we deduce that the NOT NULL > index is ok due to the strict join quals. Ah. So the index is okay to use as far as the final result is concerned, but it's not okay for the purpose to which it's being put. I concur that we'd better just not use partial indexes in relation_has_unique_index_for. regards, tom lane