From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: jsonb and nested hstore |
Date: | 2014-02-05 18:10:50 |
Message-ID: | 52F27EAA.3000509@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/05/2014 12:48 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 02/05/2014 11:40 AM, Tom Lane wrote:
>>> switching to "binary is the same as text" may well be the most prudent
>>> path here.
>> If we do that we're going to have to live with that forever, aren't we?
> Yeah, but the other side of that coin is that we'll have to live forever
> with whatever binary format we pick, too. If it turns out to be badly
> designed, that could be much worse than eating some parsing costs during
> dump/restore.
>
> If we had infinite time/manpower, this wouldn't really be an issue.
> We don't, though, and so I suggest that this may be one of the better
> things to toss overboard.
>
>
The main reason I'm prepared to consider this is the JSON parser seems
to be fairly efficient (See Oleg's recent stats) and in fact we'd more
or less be parsing the binary format on input anyway, so there's no
proof that a binary format is going to be hugely faster (or possibly
even that it will be faster at all).
If anyone else has opinions on this sing out pretty darn soon (like the
next 24 hours or so, before I begin.)
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-02-05 18:13:40 | Re: Misaligned BufferDescriptors causing major performance problems on AMD |
Previous Message | Robert Haas | 2014-02-05 18:07:47 | Re: Prohibit row-security + inheritance in 9.4? |