Re: jsonb and nested hstore - Mailing list pgsql-hackers

On 03/03/2014 07:50 PM, Peter Geoghegan wrote:
> On Fri, Feb 28, 2014 at 2:12 PM, Peter Geoghegan <pg@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