Re: Bug in row_number() optimization

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/