Re: SQL/JSON revisited

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, e(dot)indrupskaya(at)postgrespro(dot)ru
Subject: Re: SQL/JSON revisited
Date: 2023-03-06 03:18:39
Message-ID: CA+HiwqHgDFsJLjc9nOxx+mLSK5OLYtrWko-TEmpjn1N3t=CgRA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 28, 2023 at 8:36 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Mon, Feb 27, 2023 at 4:45 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > On Tue, Feb 21, 2023 at 2:25 AM Andres Freund <andres(at)anarazel(dot)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 Content-Type Size
v8-0009-Claim-SQL-standard-compliance-for-SQL-JSON-featur.patch application/x-patch 2.8 KB
v8-0007-PLAN-clauses-for-JSON_TABLE.patch application/x-patch 70.9 KB
v8-0005-RETURNING-clause-for-JSON-and-JSON_SCALAR.patch application/x-patch 10.2 KB
v8-0008-Documentation-for-SQL-JSON-features.patch application/x-patch 48.2 KB
v8-0006-JSON_TABLE.patch application/x-patch 99.7 KB
v8-0004-SQL-JSON-functions.patch application/x-patch 51.9 KB
v8-0003-SQL-JSON-query-functions.patch application/x-patch 195.5 KB
v8-0002-IS-JSON-predicate.patch application/x-patch 42.9 KB
v8-0001-SQL-JSON-constructors.patch application/x-patch 157.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-03-06 04:29:50 Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?
Previous Message Soumyadeep Chakraborty 2023-03-06 02:10:27 pg_rewind: Skip log directory for file type check like pg_wal