Re: jsonb and nested hstore

On Thu, Mar 13, 2014 at 6:15 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Wed, Mar 12, 2014 at 01:58:14PM -0700, Peter Geoghegan wrote:
>> The use case you describe here doesn't sound like something similar to
>> full text search. It sounds like something identical.
>>
>> In any case, let's focus on what we have right now. I think that the
>> indexing facilities proposed here are solid. In any case they do not
>> preclude working on better indexing strategies as the need emerges.
>
> Keep in mind that if we ship an index format, we are going to have
> trouble changing the layout because of pg_upgrade. pg_upgrade can mark
> the indexes as invalid and force users to reindex, but that is less than
> idea.

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?
--
greg