Re: BUG #17618: unnecessary filter column <> text even after adding index
Tom Lane <tgl@sss.pgh.pa.us>
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
Date: 2022-09-24T00:04:51Z
Lists: pgsql-bugs
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
Commits
-
Produce more-optimal plans for bitmap scans on boolean columns.
- 042c9091f0fc 16.0 landed