Peter Geoghegan <p...@heroku.com> writes: > On Tue, Apr 8, 2014 at 2:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> (BTW, wasn't there some discussion of changing our minds about which >> one is the default? We already have one bug report complaining about >> jsonb_ops' size restriction, so that seems to be evidence in favor >> of changing ...)
> Yes, there was. I very nearly came down on the side of making > jsonb_hash_ops the default, but given that it doesn't make all > operators indexable, I ultimately decided against supporting that > course of action. I thought that that would be an odd limitation for > the default GIN opclass to have. It was a very close call in my mind, > and if you favor changing the default now, in light of the few > complaints we've heard, I think that's a reasonable decision. That > said, as I noted in the main -bugs thread, the case presented is > fairly atypical. Well, let me see if I understand the situation correctly: * jsonb_ops supports more operators * jsonb_hash_ops produces smaller, better-performing indexes * jsonb_ops falls over on inputs with wide field values, but jsonb_hash_ops does not If that's an accurate summary then I would say that we've got the default backwards. I would much rather tell people "you can have more operators supported, but here are the tradeoffs" than have a default that fails under evidently-not-so-improbable cases. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers