Re: POC, WIP: OR-clause support for indexes - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: POC, WIP: OR-clause support for indexes
Date
Msg-id 1d5131fc-cd6c-4f61-8ba0-e61c518b168d@gmail.com
Whole thread Raw
In response to Re: POC, WIP: OR-clause support for indexes  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: POC, WIP: OR-clause support for indexes
Re: POC, WIP: OR-clause support for indexes
List 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 by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: allowing extensions to control planner behavior
Next
From: Peter Smith
Date:
Subject: Re: Pgoutput not capturing the generated columns