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