Re: Declaring a strict function returns not null / eval speed - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Declaring a strict function returns not null / eval speed
Date
Msg-id 20191021152004.tczfyozgc5yjx4vw@alap3.anarazel.de
Whole thread Raw
In response to Re: Declaring a strict function returns not null / eval speed  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Declaring a strict function returns not null / eval speed
List pgsql-hackers
Hi,

On 2019-10-20 10:27:19 -0400, Tom Lane wrote:
> "RETURNS NOT NULL", perhaps?  That'd have the advantage of not requiring
> any new keyword.

That could work.


> I'm a little bit skeptical of the actual value of adding this additional
> level of complexity, but I suppose we can't determine that reliably
> without doing most of the work :-(

Depends a bit on what case we're concerned about improving. What brought
me onto this was the concern that actually a good bit of the overhead of
computing aggregate transition functions is often the checks whether the
transition value has become NULL. And that for a lot of the more common
aggregates that's unnecessary, as they'll never do so.  That case is
pretty easy to test, we can just stop generating the relevant expression
step and do a few micro benchmarks.

Obviously for the planner taking advantage of that fact, it's more work...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: intermittent test failure on Windows
Next
From: "Joe Nelson"
Date:
Subject: Re: Proposal: Make use of C99 designated initialisers for nulls/values arrays