Re: jsonb and nested hstore

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
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 04:01:50
Message-ID: CAM3SWZSctwY2Xz1BTxG08OkpKEE48Zu0c+P9DfVV8J=py5eW0g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 3, 2014 at 7:39 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
>> 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'm sure that's true, but it's not our immediate concern. We need to
> think very hard about it to get everything we want, but we also need
> to think somewhat harder about it in order to get even a basic jsonb
> type committed.

By the way, I think it would be fine to defer adding many of the new
hstore operators and functions until 9.5 (as hstore infrastructure, or
in-core jsonb infrastructure, or anything else), if you felt you had
to, provided that you included just those sufficient to create jsonb
operator classes (plus the operator classes themselves, of course).
There is absolutely no question about having to do this for
B-Tree...why not go a couple of operator classes further?

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2014-03-04 04:07:11 Re: contrib/cache_scan (Re: What's needed for cache-only table scan?)
Previous Message Amit Kapila 2014-03-04 03:51:27 Re: Patch: show relation and tuple infos of a lock to acquire