On Thu, Mar 13, 2014 at 4:21 PM, Alexander Korotkov <aekorot...@gmail.com> wrote: > On Thu, Mar 13, 2014 at 1:21 PM, Greg Stark <st...@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.
That's right ! Should we do these now, that's the question. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
