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: | 50F445CB.90905@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
<https://bitbucket.org/adunstan/pgdevel/commits/139043dba7e6b15f1f9f7675732bd9dae1fb6497>)
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.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-01-14 17:52:24 | Re: bugfix: --echo-hidden is not supported by \sf statements |
Previous Message | Robert Haas | 2013-01-14 17:50:24 | Re: [PERFORM] Slow query: bitmap scan troubles |