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 1orMtC-0003tz-7f for pgsql-bugs@arkaria.postgresql.org; Sat, 05 Nov 2022 17:23:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1orMtA-00076g-Or for pgsql-bugs@arkaria.postgresql.org; Sat, 05 Nov 2022 17:23:24 +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 1orMtA-00076W-GZ for pgsql-bugs@lists.postgresql.org; Sat, 05 Nov 2022 17:23:24 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1orMt8-0001Tk-Hm for pgsql-bugs@lists.postgresql.org; Sat, 05 Nov 2022 17:23:24 +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 2A5HNK9O2619372; Sat, 5 Nov 2022 13:23:20 -0400 From: Tom Lane To: Jeff Janes cc: sindysenorita@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17618: unnecessary filter column <> text even after adding index In-reply-to: <946195.1663718159@sss.pgh.pa.us> References: <17618-7a2240bfaa7e84ae@postgresql.org> <349136.1663601052@sss.pgh.pa.us> <739953.1663701274@sss.pgh.pa.us> <946195.1663718159@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Tue, 20 Sep 2022 19:55:59 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2619370.1667669000.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 05 Nov 2022 13:23:20 -0400 Message-ID: <2619371.1667669000@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: >> I wonder if that isn't backwards, ie we should prefer to put duplicates >> in bitmapqualorig (the recheck condition) instead of qpqual (the filter= ). >> If my head is screwed on correctly today, that should allow us to skip >> checking the condition much of the time, and the skip would be safe >> if the index is correctly asserting that no recheck is needed. > Flipping the removal around has the effect I expected on the plan shape, > but some of the regression test queries now give the wrong answer, so > there's something faulty about that analysis. BTW, after looking more closely I see my mistake. An example of the sort of plan that fails with that change is Sort Sort Key: proname -> Bitmap Heap Scan on pg_proc - Filter: (proname ~~ 'RI\_FKey%del'::text) + Recheck Cond: (proname ~~ 'RI\_FKey%del'::text) -> Bitmap Index Scan on pg_proc_proname_args_nsp_index Index Cond: ((proname >=3D 'RI_FKey'::text) AND (proname <= 'RI_FKez'::text)) (6 rows) The difficulty here is pretty obvious: the original clause is stricter than the index conditions generated from it. So even if the index enforces the index conditions exactly, we still need to check the original clause, and so it can't be relegated to the recheck field. To improve this, we'd need to track which elements of bitmapqualorig correspond exactly to index conditions, which we don't do ATM. regards, tom lane