From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
cc: Jeff Janes <jeff.janes@gmail.com>, sindysenorita@gmail.com,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17618: unnecessary filter column <> text even after adding
 index
In-reply-to: 
 <CAMbWs4-5CtCGx_nbzfPFTtDCXjmtCOR3vb-OfK4eNEAKwLQPSQ@mail.gmail.com>
References: <17618-7a2240bfaa7e84ae@postgresql.org>
 <349136.1663601052@sss.pgh.pa.us>
 <CAMkU=1wqvsMwnQTrQ0zoRo2AkYhuEY-RuzpaXrvz7iNu38CVqg@mail.gmail.com>
 <739953.1663701274@sss.pgh.pa.us> <946195.1663718159@sss.pgh.pa.us>
 <CAMbWs4-o-VLk3gXqz7W7ZS384S5mvW5noB8f_BKzU_c77DBjXg@mail.gmail.com>
 <2100290.1663942209@sss.pgh.pa.us>
 <CAMbWs4-5CtCGx_nbzfPFTtDCXjmtCOR3vb-OfK4eNEAKwLQPSQ@mail.gmail.com>
Comments: In-reply-to Richard Guo <guofenglinux@gmail.com>
	message dated "Sat, 24 Sep 2022 07:54:02 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2174558.1663977891.1@sss.pgh.pa.us>
Date: Fri, 23 Sep 2022 20:04:51 -0400
Message-ID: <2174559.1663977891@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2174559.1663977891%40sss.pgh.pa.us>
Precedence: bulk

Richard Guo <guofenglinux@gmail.com> writes:
> On Fri, Sep 23, 2022 at 10:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Richard Guo <guofenglinux@gmail.com> writes:
>>> So I think we need to run eval_const_expressions on indexquals before we
>>> check for duplicate clauses, something like attached.

>> [ squint... ]  Surely that was done long before we ever get here?

> We should have already done that long before. It seems afterwards we may
> do additional transformation on indexquals. In this case with a boolean
> index, I can see we convert the indexqual to form 'indexkey = TRUE' in
> match_boolean_index_clause.

Of course, but what about that transformation would introduce something
that eval_const_expressions could simplify?  (Actually, now that I think
about it, I think eval_const_expressions would break it completely because
it'd re-canonicalize the expression as just 'indexkey', exactly what we
don't want here.)  In any case, if there's something between the
eval_const_expressions pass and createplan.c that introduces simplifiable
expressions, I think it's on that something's head to re-simplify; we
don't want to do something so expensive in a main code path if it's
usually going to be a complete waste.

			regards, tom lane