On 03/03/2014 07:50 PM, Peter Geoghegan wrote:
On Fri, Feb 28, 2014 at 2:12 PM, Peter Geoghegan <p...@heroku.com> wrote:
In order to make a rational decision to do the work incrementally, we
need to know what we're putting off until 9.5. AFAICT, we have these
operator classes that work fine with jsonb for the purposes of
hstore-style indexing (the hstore operator classes). Wasn't that the
point? When there is a dedicated set of jsonb operator classes, what
will be different about them, other than the fact that they won't be
hstore operator classes? A decision predicated on waiting for those to
come in 9.5 must consider what we're actually waiting for, and right
now that seems very hazy.
I really would like an answer to this question. Even if I totally
agreed with Andrew's assessment of the relative importance of having
jsonb be an in-core type, versus having some more advanced indexing
capabilities right away, this is still a very salient question.
(Taking a break from some frantic customer work)
My aim for 9.4, given constraints of both the development cycle and my
time budget, has been to get jsonb to a point where it has equivalent
functionality to json, so that nobody is forced to say "well I'll have
to use json because it lacks function x." For the processing functions,
i.e. those that don't generate json from non-json, this should be true
with what's proposed. The jsonb processing functions should be about as
fast as, or in some cases significantly faster than, their json
equivalents. Parsing text input takes a little longer (surprisingly
little, actually), and reserializing takes significantly longer - I
haven't had a chance to look and see if we can improve that. Both of
these are more or less expected results.
For 9.5 I would hope that we have at least the equivalent of the
proposed hstore classes. But that's really just a start. Frankly, I
think we need to think a lot harder about how we want to be able to
index this sort of data. The proposed hstore operators appear to me to
be at best just scratching the surface of that. I'd like to be able to
index jsonb's #> and #>> operators, for example. Unanchored subpath
operators could be an area that's interesting to implement and index.
I also would like to see some basic insert/update/delete/merge operators
for json/jsonb - that's an area I wanted to work on for this lease but
wasn't able to arrange.
Note that future developments is a major topic of my pgcon talk, and I'm
hoping that we can get some good discussion going there.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
