On 28.11.2022 03:23, David Rowley wrote:
> On Sat, 26 Nov 2022 at 05:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Sergey Shinderuk <s.shinderuk@postgrespro.ru> writes:
>>> What about user-defined operators? I created my own <= operator for int8
>>> which returns true on null input, and put it in a btree operator class.
>>> Admittedly, it's weird that (null <= 1) evaluates to true. But does it
>>> violate the contract of the btree operator class or something? Didn't
>>> find a clear answer in the docs.
>>
>> It's pretty unlikely that this would work during an actual index scan.
>> I'm fairly sure that btree (and other index AMs) have hard-wired
>> assumptions that index operators are strict.
>
> If we're worried about that then we could just restrict this
> optimization to only work with strict quals.
Not sure this is necessary if btree operators must be strict anyway.
> The proposal to copy the datums into the query context does not seem
> to me to be a good idea. If there are a large number of partitions
> then it sounds like we'll leak lots of memory. We could invent some
> partition context that we reset after each partition, but that's
> probably more complexity than it would be worth.
Ah, good point.
> I've attached a draft patch to move the code to nullify the aggregate
> results so that's only done once per partition and adjusted the
> planner to limit this to strict quals.
Not quite sure that we don't need to do anything for the
WINDOWAGG_PASSTHROUGH_STRICT case. Although, we won't return any more
tuples for the current partition, we still call ExecProject with
dangling pointers. Is it okay?
+ if (!func_strict(opexpr->opfuncid))
+ return false;
Should return true instead?
--
Sergey Shinderuk https://postgrespro.com/
