pgsql: SQL/JSON: Avoid initializing unnecessary ON ERROR / ON EMPTY ste
SQL/JSON: Avoid initializing unnecessary ON ERROR / ON EMPTY steps
When the ON ERROR / ON EMPTY behavior is to return NULL, returning
NULL directly from ExecEvalJsonExprPath() suffices. Therefore, there's
no need to create separate steps to check the error/empty flag or
those to evaluate the the constant NULL expression. This speeds up
common cases because the default ON ERROR / ON EMPTY behavior for
JSON_QUERY() and JSON_VALUE() is to return NULL. However, these steps
are necessary if the RETURNING type is a domain, as constraints on the
domain may need to be checked.
Reported-by: Jian He <jian.universality@gmail.com>
Author: Jian He <jian.universality@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Discussion: /messages/by-id/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/3a97460970f344660971ee75d7f5a181bf87f633
Modified Files
--------------
src/backend/executor/execExpr.c | 30 ++++++++++++++++++++++--------
1 file changed, 22 insertions(+), 8 deletions(-)
On Fri, Sep 6, 2024 at 12:07 PM Amit Langote <amitlan@postgresql.org> wrote:
SQL/JSON: Avoid initializing unnecessary ON ERROR / ON EMPTY steps
When the ON ERROR / ON EMPTY behavior is to return NULL, returning
NULL directly from ExecEvalJsonExprPath() suffices. Therefore, there's
no need to create separate steps to check the error/empty flag or
those to evaluate the the constant NULL expression. This speeds up
common cases because the default ON ERROR / ON EMPTY behavior for
JSON_QUERY() and JSON_VALUE() is to return NULL. However, these steps
are necessary if the RETURNING type is a domain, as constraints on the
domain may need to be checked.Reported-by: Jian He <jian.universality@gmail.com>
Author: Jian He <jian.universality@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Discussion: /messages/by-id/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17Branch
------
masterDetails
-------
https://git.postgresql.org/pg/commitdiff/3a97460970f344660971ee75d7f5a181bf87f633Modified Files
--------------
src/backend/executor/execExpr.c | 30 ++++++++++++++++++++++--------
1 file changed, 22 insertions(+), 8 deletions(-)
This or one of the other of my recent commits have broken some BF
animals, so reverting for now.
--
Thanks, Amit Langote
Amit Langote <amitlangote09@gmail.com> writes:
This or one of the other of my recent commits have broken some BF
animals, so reverting for now.
Unfiltered EXPLAIN VERBOSE output in a regression test is a
guaranteed fail.
regards, tom lane
On Fri, Sep 6, 2024 at 1:09 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Amit Langote <amitlangote09@gmail.com> writes:
This or one of the other of my recent commits have broken some BF
animals, so reverting for now.Unfiltered EXPLAIN VERBOSE output in a regression test is a
guaranteed fail.
Yes, thanks for the note. Will change the test case to test what are
deparsing related changes in some other manner.
--
Thanks, Amit Langote
Amit Langote <amitlangote09@gmail.com> writes:
Yes, thanks for the note. Will change the test case to test what are
deparsing related changes in some other manner.
I usually prefer to test ruleutils.c by deparsing a suitable view.
regards, tom lane
On Fri, Sep 6, 2024 at 1:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Amit Langote <amitlangote09@gmail.com> writes:
Yes, thanks for the note. Will change the test case to test what are
deparsing related changes in some other manner.I usually prefer to test ruleutils.c by deparsing a suitable view.
Yeah, other tests in that file use that method too, so going with
that. Actually, a few other tests in that file do use VERBOSE, but
with COSTS OFF, so unbitten so far by JIT summary accidentally being
printed out.
--
Thanks, Amit Langote