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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)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/