On Thu, Mar 13, 2014 at 1:21 PM, Greg Stark <stark@mit.edu> wrote:
Well these are just normal gin and gist indexes. If we want to come up
with new index operator classess we can still do that and keep the old ones if necessary. Even that seems pretty unlikely from past experience.
I'm actually pretty sanguine even about keeping the GIST opclass. If it has bugs then the bugs only affect people who use this non-default opclass and we can fix them. It doesn't risk questioning any basic design choices in the patch.
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?
A couple of thoughts from me:
1) We can evade length limitation if GIN index by truncating long values and setting recheck flag. We can introduce some indicator of truncated value like zero byte at the end.
2) jsonb_hash_ops can be extended to handle keys queries too. We can preserve one bit in hash as flag indicating whether it's a hash of key or hash of path to value. For sure, such index would be a bit larger. Also, jsonb_hash_ops can be split into two: with and without keys.