Re: JSON for PG 9.2

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: Peter van Hardenberg <pvh(at)pvh(dot)ca>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com>
Subject: Re: JSON for PG 9.2
Date: 2011-12-13 03:08:28
Message-ID: 4EE6C1AC.8080307@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/12/2011 08:46 PM, Daniel Farina wrote:
> On Mon, Dec 12, 2011 at 5:36 PM, Andrew Dunstan<andrew(at)dunslane(dot)net> wrote:
>> The trouble with using JSON.parse() as a validator is that it's probably
>> doing way too much work. PLV8 is cool, and I keep trying to get enough time
>> to work on it more, but I don't think it's a substitute for a JSON type with
>> a purpose built validator and some native operations. I think these efforts
>> can continue in parallel.
> Hmm. Maybe? While I'm sure things could be faster, we've had results
> that are fast enough to be usable even with constant reparsing. Here
> are some microbenchmarks I did some time ago where I tried to find the
> overhead of calling JSON.parse and doing some really simple stuff in
> V8 that I thought would maximize the amount of constant-time overhead:
>
> https://gist.github.com/1150804
>
> On my workstation, one core was able to do 130,000 JSON.parses + other
> stuff necessary to create an index per second. One could maybe try to
> improve the speed and memory footprint on large documents by having
> validators that don't actually build the V8 representation and
> possibly defining a space of operators that are known to build, by
> induction, valid JSON without rechecks.
>
> But in the end, I think there's already a class of problem where the
> performance plv8 provides is already quite sufficient, and provides a
> much more complete and familiar approach to the problem of how people
> choose to navigate, project, and manipulate JSON documents.
>
> I also haven't tried this for larger documents, as I was trying to get
> a sense of how much time was spent in a few primitive operations, and
> not testing performance with regard to document length.
>

Yes, I didn't mean to say it's not fast. For many cases I agree it is
probably fast enough.

But in the end PLV8 is likely to remain an addon - nice as it can be I
doubt the core team will want to add another PL to the core code,
especially one written in C++. If we want a JSON type built in, which
many people seem to want, we'll need to do it without the support of
PLV8, I think.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2011-12-13 03:28:05 Re: patch : Allow toast tables to be moved to a different tablespace
Previous Message Shigeru Hanada 2011-12-13 02:46:10 Re: pgsql_fdw, FDW for PostgreSQL server