Re: POC, WIP: OR-clause support for indexes
От | Andrei Lepikhov |
---|---|
Тема | Re: POC, WIP: OR-clause support for indexes |
Дата | |
Msg-id | 1d5131fc-cd6c-4f61-8ba0-e61c518b168d@gmail.com обсуждение исходный текст |
Ответ на | Re: POC, WIP: OR-clause support for indexes (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: POC, WIP: OR-clause support for indexes
Re: POC, WIP: OR-clause support for indexes |
Список | pgsql-hackers |
On 10/4/24 03:15, Peter Geoghegan wrote: > On Tue, Oct 1, 2024 at 6:25 AM Alexander Korotkov <aekorotkov@gmail.com> wrote: >> I think this patchset got much better, and it could possible be >> committed after another round of cleanup and comment/docs improvement. >> It would be very kind if you share your view on the decisions made in >> this patchset. Let me provide a standpoint to help Alexander. The origin reason was - to avoid multiple BitmapOr, which has some effects at the planning stage (memory consumption, planning time) and execution (execution time growth). IndexScan also works better with a single array (especially a hashed one) than with a long list of clauses. Another reason is that by spending some time identifying common operator family and variable-side clause equality, we open a way for future cheap improvements like removing duplicated constants. Who knows, maybe we will be capable of using this code to improve cardinality estimations. According to your proposal, we have had such casting to the common type in previous versions. Here, we avoid it intentionally: the general idea is about long lists of constants, and such casting causes questions about performance. Do I want it in the core? Yes, I do! But may we implement it a bit later to have time to probe the general method and see how it flies? -- regards, Andrei Lepikhov
В списке pgsql-hackers по дате отправления: