On Sat, May 10, 2014 at 2:52 PM, Peter Geoghegan <p...@heroku.com> wrote:
> I've added a wildcard to the rhs jsonb here, which of course won't
> work, the proximate cause being that that simply isn't valid jsonb.
> It's also something inherently impossible to support with the current
> jsonb_hash_op's indexing strategy. That only hashes elements and
> values, mixing in keys from all outer nesting levels (so it's possible
> for there to be 0 *nentries).
It occurs to me that this could be a particular problem for
jsonb_hash_ops. Consider this jsonb:
'{"a":{}}'::jsonb
In one sense, the outermost level's "a" key does have a value: an
empty object. So we may test containment in an indexable fashion like
this:
select * from foo where j @> '{"a":{}}'::jsonb
But in another sense, the sense that is relevant to jsonb_hash_ops, it
does not. There would be *no* GIN keys passed back from
gin_extract_jsonb_hash() if it were tasked with extracting keys from
this rhs jsonb.
Now, I'm not all that worried about this, because this is surely an
odd-ball use case, particularly for jsonb_hash_ops where no keys are
separately indexed (separately from *primitive* elements/values).
However, it is worth noting in the documentation in my view. I attach
a doc patch that adds this.
--
Peter Geoghegan
*** a/doc/src/sgml/json.sgml
--- b/doc/src/sgml/json.sgml
*************** SELECT jdoc->'guid', jdoc->'name'
*** 453,458 ****
--- 453,463 ----
particularly when queries contain keys that appear frequently in the
data. Therefore search operations typically perform better
than with the default operator class.
+ <literal>jsonb_hash_ops</literal> indexes are ill-suited to cases
+ where there are frequent containment queries that test containment
+ of a <type>jsonb</> <emphasis>without</> any primitive object
+ values or array elements, as when searching for JSON documents
+ matching a particular structure.
</para>
<para>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
