Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

On Sat, May 10, 2014 at 5:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm not sure whether we have consensus to rename jsonb_hash_ops to
> jsonb_path_ops, but since time is so short I went ahead and made a draft
> patch to do so (attached). Probably the most interesting part of this is
> the new text in json.sgml explaining the difference between the two
> opclasses. I also added a paragraph about the empty-query hazard that
> Peter mentions. Do people think this discussion is correct and useful?

I for one am fine with the name change you propose.

> + especially if
> + there are a very large number of rows containing any single one of the
> + three keys

I suggest that you phrase this as "three index items".

> + A disadvantage of the <literal>jsonb_path_ops</literal> approach is
> + that it produces no index entries for JSON structures not containing
> + any values, such as <literal>{"a": {}}</literal>. If a search for

I suggest "any values or elements".

Even though I previously called hashing an implementation detail, we
are bound to have to mention it in passing when discussing the
limitations of jsonb_hash_ops/jsonb_path_ops. I think that you should
proceed with committing the entire patch, including the doc changes
that discuss implementation details around the two GIN opclasses.

--
Peter Geoghegan