From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Claudio Freire <klaussfreire(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Jan Wieck <jan(at)wi3ck(dot)info> |
Subject: | Re: jsonb format is pessimal for toast compression |
Date: | 2014-09-15 23:05:59 |
Message-ID: | 541770D7.9020701@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/15/2014 02:16 PM, Robert Haas wrote:
> On Mon, Sep 15, 2014 at 3:09 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> On 09/15/2014 10:23 AM, Claudio Freire wrote:
>>> Now, large small keys could be 200 or 2000, or even 20k. I'd guess
>>> several should be tested to find the shape of the curve.
>>
>> Well, we know that it's not noticeable with 200, and that it is
>> noticeable with 100K. It's only worth testing further if we think that
>> having more than 200 top-level keys in one JSONB value is going to be a
>> use case for more than 0.1% of our users. I personally do not.
>
> FWIW, I have written one (1) application that uses JSONB and it has
> one sub-object (not the top-level object) that in the most typical
> configuration contains precisely 270 keys. Now, granted, that is not
> the top-level object, if that distinction is actually relevant here,
> but color me just a bit skeptical of this claim anyway. This was just
> a casual thing I did for my own use, not anything industrial strength,
> so it's hard to believe I'm stressing the system more than 99.9% of
> users will.
Actually, having the keys all at the same level *is* relevant for the
issue we're discussing. If those 270 keys are organized in a tree, it's
not the same as having them all on one level (and not as problematic).
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-09-15 23:19:32 | Re: Suspicious check (src/backend/access/gin/gindatapage.c) |
Previous Message | Peter Geoghegan | 2014-09-15 22:42:20 | Re: Collation-aware comparisons in GIN opclasses |