From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
cc: sindysenorita@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17618: unnecessary filter column <> text even after adding
 index
In-reply-to: <739953.1663701274@sss.pgh.pa.us>
References: <17618-7a2240bfaa7e84ae@postgresql.org>
 <349136.1663601052@sss.pgh.pa.us>
 <CAMkU=1wqvsMwnQTrQ0zoRo2AkYhuEY-RuzpaXrvz7iNu38CVqg@mail.gmail.com>
 <739953.1663701274@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Tue, 20 Sep 2022 15:14:34 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <946194.1663718159.1@sss.pgh.pa.us>
Date: Tue, 20 Sep 2022 19:55:59 -0400
Message-ID: <946195.1663718159@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/946195.1663718159%40sss.pgh.pa.us>
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.

			regards, tom lane