On 28.11.2022 03:23, David Rowley wrote:
On Sat, 26 Nov 2022 at 05:19, Tom Lane <t...@sss.pgh.pa.us> wrote:
Sergey Shinderuk <s.shinde...@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/
