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)