| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Nico Williams <nico(at)cryptonector(dot)com>, Christian Convey <christian(dot)convey(at)gmail(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Tackling JsonPath support |
| Date: | 2016-12-06 03:10:41 |
| Message-ID: | 06210946-2563-acce-3f77-fa4a17e6d03f@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/28/16 12:38 PM, Nico Williams wrote:
> The internal representation of JSON data is bound to be
> completely different, no doubt
Actually, that could be a good thing. The internal storage of JSONB is
optimized for compress-ability, but that imposes a substantial overhead
to calls that are searching for a particular key in a document. This
gets *really* bad if you make nested expansion calls (ie: json->'a'->'b').
ExpandedObject support means we're not stuck with the same
representation in-memory as on-disk though. While we could create our
own internal representation, it seems a bit silly to reinvent that wheel
if we don't need to. Bonus points if it would also throw an error if you
fed it duplicated object keys.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-12-06 03:10:46 | Re: [COMMITTERS] pgsql: Permit dump/reload of not-too-large >1GB tuples |
| Previous Message | Andres Freund | 2016-12-06 02:20:11 | Re: [COMMITTERS] pgsql: Add support for restrictive RLS policies |