Skip site navigation (1) Skip section navigation (2)

Re: json api WIP patch

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: json api WIP patch
Date: 2013-01-14 17:52:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 01/14/2013 11:32 AM, Robert Haas wrote:
> So, how much performance does this lose on json_in() on a large
> cstring, as compared with master?

That's a good question. I'll try to devise a test.

> I can't shake the feeling that this is adding a LOT of unnecessary
> data copying.  For one thing, instead of copying every single lexeme
> (including the single-character ones?) out of the original object, we
> could just store a pointer to the offset where the object starts and a
> length, instead of copying it.

In the pure pares case (json_in, json_reccv) nothing extra should be 
copied. On checking this after reading the above I found that wasn't 
quite the case, and some lexemes (scalars and field names, but not 
punctuation) were being copied when not needed. I have made a fix (see 
which I will include in the next version I publish.

In the case of string lexemes, we are passing back a de-escaped version, 
so just handing back pointers to the beginning and end in the input 
string doesn't work.

> This is also remarkably thin on comments.

Fair criticism. I'll work on that.

Thanks for looking at this.



In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2013-01-14 17:52:24
Subject: Re: bugfix: --echo-hidden is not supported by \sf statements
Previous:From: Robert HaasDate: 2013-01-14 17:50:24
Subject: Re: [PERFORM] Slow query: bitmap scan troubles

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group