Thread: Should we introduce a "really strict" volatility about return values?

Should we introduce a "really strict" volatility about return values?

From
Andres Freund
Date:
Hi,

Currently a good bit of time evaluation more complex expressions is
spent checking whether a strict [transition] function should be called
or not. There's a good number of cases where we could optimize that away
based on the underlying data - if e.g. a slot column refers to a NOT
NULL column (cf [1]), we do not need to do the NOT NULL checks.

A significant limit of that is that for even slightly morecomplex
expressions, say a + b + c that doesn't work for all the operator
invocations, because even though functions like int8pl are strict, we do
*not* guarantee that the return value is also strict.

Thus I wonder if we shouldn't introduce a 'really strict' volatility
level that signals, in addition to normal strict guarantees, that no
other case returns NULL. In a lot of cases that should allow us to
completely eliminate strictness checks from execution.

I don't plan to work on this anytime soon, but I though it's interesting
enough to put out there and see what others think.

Greetings,

Andres Freund

[1] http://archives.postgresql.org/message-id/20171206093717.vqdxe5icqttpxs3p%40alap3.anarazel.de


Re: Should we introduce a "really strict" volatility about return values?

From
Robert Haas
Date:
On Thu, Jan 25, 2018 at 6:51 PM, Andres Freund <andres@anarazel.de> wrote:
> I don't plan to work on this anytime soon, but I though it's interesting
> enough to put out there and see what others think.

I mean, if it buys enough performance, it's probably worth doing.
Sort of annoying to have to introduce more syntax, but it could be
worth it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company