public inbox for [email protected]  

help / color / mirror / Atom feed

From: Peter Geoghegan <[email protected]>
To: Heikki Linnakangas <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Greg Stark <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Gavin Flower <[email protected]>
Cc: David E. Wheeler <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)
Date: Sat, 10 May 2014 17:25:49 -0700
Message-ID: <CAM3SWZQpg8cX+MccHd38KCQMgD9Leh-4BNBFnV-8gh5+Rnb1Hg@mail.gmail.com> (raw)
In-Reply-To: <CAM3SWZTerM-f8nhmuatR-YhPiMwrqR01=TwtCNM1E9PERkvAAA@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAM-w4HOQ+ynm70Cgr4BwMqMc0jfL_8EZAwG2UD6r=EehjH3OOw@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CAM3SWZTerM-f8nhmuatR-YhPiMwrqR01=TwtCNM1E9PERkvAAA@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>

On Sat, May 10, 2014 at 2:52 PM, Peter Geoghegan <[email protected]> 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


-- 
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Attachments:

  [text/x-patch] jsonb_structure_containment.patch (680B, 2-jsonb_structure_containment.patch)
  download | inline diff:
*** a/doc/src/sgml/json.sgml
--- b/doc/src/sgml/json.sgml
*************** SELECT jdoc-&gt;'guid', jdoc-&gt;'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>

view thread (65+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)
  In-Reply-To: <CAM3SWZQpg8cX+MccHd38KCQMgD9Leh-4BNBFnV-8gh5+Rnb1Hg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox