On 10/1/19 9:38 AM, Andres Freund wrote:
We spend a surprising amount of time during expression evaluation to
reevaluate whether input to a strict function (or similar) is not null,
even though the value either comes from a strict function, or a column
declared not null.
Now you can rightfully say that a strict function still can return NULL,
even when called with non-NULL input. But practically that's quite rare.
Most of the common byvalue type operators are strict, and approximately
none of those return NULL when actually called.
That makes me wonder if it's worthwhile to invent a function property
declaring strict strictness or such. It'd allow for some quite noticable
improvements for e.g. queries aggregating a lot of rows, we spend a fair
time checking whether the transition value has "turned" not null. I'm
about to submit a patch making that less expensive, but it's still
expensive.
I can also imagine that being able to propagate NOT NULL further up the
parse-analysis tree could be beneficial for planning, but I've not
looked at it in any detail.
Agreed, this sounds like something useful to do since virtually all
strict functions cannot return NULL, especially the ones which are used
in tight loops. The main design issue seems to be to think up a name for
this new level of strictness which is not too confusing for end users.
We also have a handful of non-strict functions (e.g. concat() and range
constructors like tstzrange()) which are guaranteed to never return
NULL, but I do not think they are many enough or performance critical
enough to be worth adding this optimization to.
Andreas
