Re: jsonb format is pessimal for toast compression

On 09/16/2014 09:54 AM, Robert Haas wrote:
> On Tue, Sep 16, 2014 at 12:47 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> On 09/16/2014 06:31 AM, Robert Haas wrote:
>>> On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan <pg@heroku.com> wrote:
>>>> On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus <josh@agliodbs.com> wrote:
>>>>> 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).
>>>>
>>>> I believe Robert meant that the 270 keys are not at the top level, but
>>>> are at some level (in other words, some object has 270 pairs). That is
>>>> equivalent to having them at the top level for the purposes of this
>>>> discussion.
>>>
>>> Yes, that's exactly what I meant.
>>>
>>>> FWIW, I am slightly concerned about weighing use cases around very
>>>> large JSON documents too heavily. Having enormous jsonb documents just
>>>> isn't going to work out that well, but neither will equivalent designs
>>>> in popular document database systems for similar reasons. For example,
>>>> the maximum BSON document size supported by MongoDB is 16 megabytes,
>>>> and that seems to be something that their users don't care too much
>>>> about. Having 270 pairs in an object isn't unreasonable, but it isn't
>>>> going to be all that common either.
>>
>> Well, I can only judge from the use cases I personally have, none of
>> which involve more than 100 keys at any level for most rows.  So far
>> I've seen some people argue hypotetical use cases involving hundreds of
>> keys per level, but nobody who *actually* has such a use case.
> 
> I already told you that I did, and that it was the only and only app I
> had written for JSONB.

Ah, ok, I thought yours was a test case.  Did you check how it performed
on the two patches at all?  My tests with 185 keys didn't show any
difference, including for a "last key" case.


-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com