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

Peter Geoghegan <pg@heroku.com> writes:
> On Sat, May 10, 2014 at 5:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> +     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".

Good idea --- "key" is overloaded in this discussion.  I'd meant to use
"item" uniformly for the index entries, but missed some spots.

>> +     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".

Meh --- the previous para is also using "value" to include array elements,
and I don't see anything in RFC 7159 suggesting that that's not preferred
terminology.  But I added a footnote to clarify:
   The technical difference between a <literal>jsonb_ops</literal>   and a <literal>jsonb_path_ops</literal> GIN index
isthat the former   creates independent index items for each key and value in the data,   while the latter creates
indexitems only for each value in the   data.<footnote><para>For this purpose, the term <quote>value</>   includes
arrayelements, though JSON terminology sometimes considers   array elements distinct from values within
objects.</para></footnote>

> 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.

I'll hold off committing till the morning to see if there are objections.
        regards, tom lane