Re: Declaring a strict function returns not null / eval speed

Moin,

On 2019-10-20 13:30, Andreas Karlsson wrote:
> 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.

STRICT NONULL? That way you could do

CREATE FUNCTION f1 ... STRICT;
CREATE FUNCTION f2 ... STRICT NONULL;
CREATE FUNCTION f3 ... NONULL;

and the last wold throw "not implementet yet"? "NEVER RETURNS NULL"
would also ryme with the existing "RETURNS NULL ON NULL INPUT", but I
find the verbosity too high.

Best regards,

Tels

--
Best regards,

Tels