Thread: 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: https://postgr.es/m/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: https://postgr.es/m/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(-) 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