Re: SQL/JSON revisited - Mailing list pgsql-hackers

From Amit Langote
Subject Re: SQL/JSON revisited
Date
Msg-id CA+HiwqHgDFsJLjc9nOxx+mLSK5OLYtrWko-TEmpjn1N3t=CgRA@mail.gmail.com
Whole thread Raw
In response to Re: SQL/JSON revisited  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: SQL/JSON revisited  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Tue, Feb 28, 2023 at 8:36 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Mon, Feb 27, 2023 at 4:45 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > On Tue, Feb 21, 2023 at 2:25 AM Andres Freund <andres@anarazel.de> wrote:
> > > Evaluating N expressions for a json table isn't a good approach, both memory
> > > and CPU efficiency wise.
> >
> > Are you referring to JsonTableInitOpaque() initializing all these
> > sub-expressions of JsonTableParent, especially colvalexprs, using N
> > *independent* ExprStates?  That could perhaps be made to work by
> > making JsonTableParent be an expression recognized by execExpr.c, so
> > that a single ExprState can store the steps for all its
> > sub-expressions, much like JsonExpr is.  I'll give that a try, though
> > I wonder if the semantics of making this work in a single
> > ExecEvalExpr() call will mismatch that of the current way, because
> > different sub-expressions are currently evaluated under different APIs
> > of TableFuncRoutine.
>
> Hmm, the idea to turn JSON_TABLE into a single expression turned out
> to be a non-starter after all, because, unlike JsonExpr, it can
> produce multiple values.  So there must be an ExprState for computing
> each column of its output rows.  As I mentioned in my other reply,
> TableFuncScanState has a list of ExprStates anyway for
> TableFunc.colexprs.  What we could do is move the ExprStates of
> TableFunc.colvalexprs into TableFuncScanState instead of making that
> part of the JSON_TABLE opaque state, as I've done in the attached
> updated patch.

Here's another version in which I've also moved the ExprStates of
PASSING args into TableFuncScanState instead of keeping them in
JSON_TABLE opaque state.  That means all the subsidiary ExprStates of
TableFuncScanState are now initialized only once during
ExecInitTableFuncScan().  Previously, JSON_TABLE related ones would be
initialized on every call of JsonTableInitOpaque().

I've also done some cosmetic changes such as renaming the
JsonTableContext to JsonTableParseContext in parse_jsontable.c and to
JsonTableExecContext in jsonpath_exec.c.


--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Soumyadeep Chakraborty
Date:
Subject: pg_rewind: Skip log directory for file type check like pg_wal
Next
From: Michael Paquier
Date:
Subject: Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?