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