Re: BUG #17618: unnecessary filter column <> text even after adding index

Поиск
Список
Период
Сортировка
От Richard Guo
Тема Re: BUG #17618: unnecessary filter column <> text even after adding index
Дата
Msg-id CAMbWs498iR-5gVbsS0DCmoeK4YNs0nny6xmW-eLvm=C-KXm-Ag@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17618: unnecessary filter column <> text even after adding index  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs

On Sat, Sep 24, 2022 at 8:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Richard Guo <guofenglinux@gmail.com> writes:
> 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.
 
Yeah, I agree that running eval_const_expressions here is expensive.
Maybe we can just do the reverse transformation in
create_bitmap_scan_plan against what we do for boolean index in
match_boolean_index_clause?

I think it's necessary to re-simplify the indexquals here, otherwise we
may fail to compare scan_clauses to indexquals correctly.

Thanks
Richard

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: BUG #17619: AllocSizeIsValid violation in parallel hash join
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: BUG #17619: AllocSizeIsValid violation in parallel hash join