Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Joseph Adams <joeyadams3(dot)14159(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 20:46:03
Message-ID: AANLkTi=BWnKi+5ZxhNN1KHGvNS0ODYC5JikQdEXTYXxV@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 19, 2010 at 3:40 PM, Joseph Adams
<joeyadams3(dot)14159(at)gmail(dot)com> wrote:
> On Tue, Oct 19, 2010 at 3: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.
>
> Speculation: the overhead involved with retrieving/sending and
> receiving/storing JSON (not to mention TOAST
> compression/decompression) will be far greater than that of
> serializing/unserializing.

I speculate that your speculation is incorrect. AIUI, we, unlike
$COMPETITOR, tend to be CPU-bound rather than IO-bound on COPY. But
perhaps less speculation and more benchmarking is in order.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-10-19 20:54:56 Re: max_wal_senders must die
Previous Message Robert Haas 2010-10-19 20:35:02 Re: max_wal_senders must die