Subject: Re: Tackling JsonPath support
To: Nico Williams <nico@cryptonector.com>,
 Christian Convey <christian.convey@gmail.com>
References: 
 <CAPfS4Zy0RCJstWT3sRhKZO6db+xxZeAL7wmOVG5QUK=P8bXWZQ@mail.gmail.com>
 <CAFj8pRA2BbWioAfA79bDdJ_JviVaUYr+5zj+sQuVrHmvJARKdw@mail.gmail.com>
 <CAPfS4ZwaPMMLUQ6AFj=t182AAce-wGcDWzP9nHqkz3nx+H2_2Q@mail.gmail.com>
 <20681.1479057226@sss.pgh.pa.us>
 <CAFj8pRDvKiQ3YcNOCeEcOEy+OKh6LFcazmOe-Tit-gHyv1e+xQ@mail.gmail.com>
 <CAPfS4Zx8v1xx_OoG6n2_K2TthNudGshfkSbk=-__N+1-z8WSwg@mail.gmail.com>
 <20161128183819.GB11117@localhost>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
Message-ID: <06210946-2563-acce-3f77-fa4a17e6d03f@BlueTreble.com>
Date: Mon, 5 Dec 2016 21:10:41 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <20161128183819.GB11117@localhost>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (protection.outlook.com: bluetreble.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Dec 2016 03:10:46.7157 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1641
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers