Re: jsonb and nested hstore

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Christophe Pettus <xof(at)thebuild(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: jsonb and nested hstore
Date: 2014-03-04 02:54:16
Message-ID: 53154058.3080002@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2014-03-04 02:59:37 Re: jsonb and nested hstore
Previous Message Peter Geoghegan 2014-03-04 02:17:10 Re: jsonb and nested hstore