On 13.3.2014 13:28, Oleg Bartunov wrote:
> On Thu, Mar 13, 2014 at 4:21 PM, Alexander Korotkov
> <aekorotkov@gmail.com> wrote:
>> 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.
>
> That's right ! Should we do these now, that's the question.
Yeah, those are basically the two solutions I proposed a few messages
back in this thread. I'm pleased I haven't proposed a complete nonsense.
The question whether do that now or wait for 9.5 is a tough one. Doing
both for 9.4 is certainly stretching the commitfest to it's limits :-(
My impression is that while (2) means rather significant implementation
changes in jsonb_hash_ops, (1) is rather straightforward. Is that
correct (e.g. how's the truncation going to work with arrays?).
If that's true, I'd like propose doing (1) for 9.4 and leaving (2) to
9.5. I'm ready to spend non-trivial amount of time testing the changes
required in (1).
regards
Tomas