Re: Tackling JsonPath support - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Tackling JsonPath support
Date
Msg-id 06210946-2563-acce-3f77-fa4a17e6d03f@BlueTreble.com
Whole thread Raw
In response to Re: Tackling JsonPath support  (Nico Williams <nico@cryptonector.com>)
List 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)



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Permit dump/reload of not-too-large >1GB tuples
Next
From: Alvaro Herrera
Date:
Subject: Re: [COMMITTERS] pgsql: Permit dump/reload of not-too-large >1GB tuples