Re: JSON for PG 9.2
От | Andrew Dunstan |
---|---|
Тема | Re: JSON for PG 9.2 |
Дата | |
Msg-id | 4EE6C1AC.8080307@dunslane.net обсуждение исходный текст |
Ответ на | Re: JSON for PG 9.2 (Daniel Farina <daniel@heroku.com>) |
Список | pgsql-hackers |
On 12/12/2011 08:46 PM, Daniel Farina wrote: > On Mon, Dec 12, 2011 at 5:36 PM, Andrew Dunstan<andrew@dunslane.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
В списке pgsql-hackers по дате отправления: