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 fdba7c11-4f3e-43d3-ac89-cab82aef0b6f@gmail.com
Whole thread Raw
In response to Re: POC, WIP: OR-clause support for indexes  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: POC, WIP: OR-clause support for indexes
List pgsql-hackers
On 1/27/25 16:50, Alexander Korotkov wrote:
> I expressed my point on this in [1].  We generally greedy about index 
> quals and there is no logic which prevent us from using a clause and 
> index qual because of its cost.  And there are many cases when this 
> causes regressions before d4378c0005.  One of examples from [1].
Ok,
Generally, I don't concern myself with the evaluation of individual 
subplans. As you mentioned, it should be a rare occurrence when this 
becomes important. My main concern is the shift in frequency of 
evaluations during execution for various reasons.
For example:

qsort(matches, n, sizeof(OrArgIndexMatch), or_arg_index_match_cmp);

To fit an index, the order of elements in the target array of the 
`ScalarArrayOpExpr` may change compared to the initial list of OR 
expressions. If there are indexes that cover the same set of columns but 
in reverse order, this could potentially alter the position of a 
Subplan. However, I believe this is a rare case; it is supported by the 
initial OR path and should be acceptable.

So, I do not have any further objections at this time.

-- 
regards, Andrei Lepikhov



pgsql-hackers by date:

Previous
From: Amul Sul
Date:
Subject: Re: Allow NOT VALID foreign key constraints on partitioned tables.
Next
From: Srinath Reddy
Date:
Subject: Re: Non-text mode for pg_dumpall