From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Terry Laurenzo <tj(at)laurenzo(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP) |
Date: | 2010-10-19 21:57:41 |
Message-ID: | AANLkTi=+u_g=RL_J5wYvtB728_HmmTJFY7QF=YqF7V-t@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 19, 2010 at 12:17 PM, Robert Haas <robertmhaas(at)gmail(dot)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.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-10-19 21:59:55 | Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP) |
Previous Message | Pavel Stehule | 2010-10-19 21:43:41 | Re: Creation of temporary tables on read-only standby servers |