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

Peter Geoghegan <pg(at)heroku(dot)com> writes:
> On Sat, May 10, 2014 at 5:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 is that the former
creates independent index items for each key and value in the data,
while the latter creates index items only for each value in the
data.<footnote><para>For this purpose, the term <quote>value</>
includes array elements, 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