On Thu, Mar 13, 2014 at 2:21 AM, Greg Stark <stark@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
