2010/10/19 Greg Stark <gsst...@mit.edu>: > On Tue, Oct 19, 2010 at 12:17 PM, Robert Haas <robertmh...@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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
