On Thu, Mar 13, 2014 at 2:21 AM, Greg Stark <st...@mit.edu> wrote: > It does sound like the main question here is which opclass should be > the default. From the discussion there's a jsonb_hash_ops which works > on all input values but supports fewer operators and a jsonb_ops which > supports more operators but can't handle json with larger individual > elements. Perhaps it's better to make jsonb_hash_ops the default so at > least it's always safe to create a default gin index?
Personally, I don't think it's a good idea to change the default. I have yet to be convinced that if you hit the GIN limitation it's an indication of anything other than that you need to reconsider your indexing choices (how often have we heard that complaint of GIN before in practice?). Even if you don't hit the limitation directly, with something like jsonb_hash_ops you're still hashing a large nested structure, very probably uselessly. Are you really going to look for an exact match to an elaborate nested structure? I would think, probably not. Now, as Alexander says, there might be a role for another (jsonb_hash_ops) opclass that separately indexes values only. I still think that by far the simplest solution is to use expressional indexes, because we index key values and array element values indifferently. Of course, nothing we have here precludes the development of such an opclass. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
