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