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 |
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 |