Re: Abnormal JSON query performance - Mailing list pgsql-bugs

From David G. Johnston
Subject Re: Abnormal JSON query performance
Date
Msg-id CAKFQuwbDmE6dNARcTru++PfrarFkPL1m2j8dBHm5PcHcJF+gvw@mail.gmail.com
Whole thread Raw
In response to Re: Abnormal JSON query performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Abnormal JSON query performance  (007reader <007reader@gmail.com>)
List pgsql-bugs
On Mon, May 14, 2018 at 8:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Mon, May 14, 2018 at 7:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> SELECT ... FROM ...some tables...,
>> jsonb_to_record(jsonbcol) AS j(id int, name text, price numeric)
>> WHERE ...
>>
>> which is something you can do today.

> ​Indeed you can - could you please point to the docs for that one?

https://www.postgresql.org/docs/current/static/functions-json.html#FUNCTIONS-JSON-PROCESSING-TABLE

​Thanks.  I was thinking you were still talking about "populate" variants of the functions and missed that you switched to the "to" variant in the final example.
 
Perhaps it'd be worth emphasizing the usefulness of jsonb_to_record[set]
a bit more, say with examples in section 8.14.

A section titled "JSON Element Extraction" under 8.14 that covers those functions in context and discusses the dynamics of multiple columns of -> invocations seem worthwhile.

"Ideally, JSON documents should each represent an atomic datum that business rules dictate cannot reasonably be further subdivided into smaller datums that could be modified independently."

See that new section should you decide to not heed the above advice, and in general converting between json and table forms.

David J.

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #15196: bogus data in lock file "postmaster.pid"
Next
From: PG Bug reporting form
Date:
Subject: BUG #15197: query tool not working