2010/10/19 Greg Stark <gsstark@mit.edu>:
> On Tue, Oct 19, 2010 at 12:17 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I think we should take a few steps back and ask why we think that
>> binary encoding is the way to go. We store XML as text, for example,
>> and I can't remember any complaints about that on -bugs or
>> -performance, so why do we think JSON will be different? Binary
>> encoding is a trade-off. A well-designed binary encoding should make
>> it quicker to extract a small chunk of a large JSON object and return
>> it; however, it will also make it slower to return the whole object
>> (because you're adding serialization overhead). I haven't seen any
>> analysis of which of those use cases is more important and why.
>>
>
> The elephant in the room is if the binary encoded form is smaller then
> it occupies less ram and disk bandwidth to copy it around. If your
> database is large that alone is the dominant factor. Doubling the size
> of all the objects in your database means halving the portion of the
> database that fits in RAM and doubling the amount of I/O required to
> complete any given operation. If your database fits entirely in RAM
> either way then it still means less RAM bandwidth used which is often
> the limiting factor but depending on how much cpu effort it takes to
> serialize and deserialize the balance could shift either way.
I am not sure, if this argument is important for json. This protocol
has not big overhead and json documents are pretty small. More - from
9.0 TOAST uses a relative aggresive compression. I would to like a
some standardised format for json inside pg too, but without using a
some external library I don't see a advantages to use a other format
then text.
Regards
Pavel
>
>
>
>
> --
> greg
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>