Re: jsonb and nested hstore

On Thu, Mar 13, 2014 at 4:21 PM, Alexander Korotkov
<aekorotkov(at)gmail(dot)com> wrote:
> On Thu, Mar 13, 2014 at 1:21 PM, Greg Stark <stark(at)mit(dot)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.