On 09/16/2014 09:54 AM, Robert Haas wrote: > On Tue, Sep 16, 2014 at 12:47 PM, Josh Berkus <j...@agliodbs.com> wrote: >> On 09/16/2014 06:31 AM, Robert Haas wrote: >>> On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan <p...@heroku.com> wrote: >>>> On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
