From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Should we introduce a "really strict" volatility about return values? |
Date: | 2018-01-25 23:51:55 |
Message-ID: | 20180125235155.2y6zls67w5w6ox4m@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2018-01-25 23:57:24 | Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump |
Previous Message | Thomas Munro | 2018-01-25 23:33:41 | Documentation of pgcrypto AES key sizes |