Re: jsonb and nested hstore

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: obartunov(at)gmail(dot)com, Tomas Vondra <tv(at)fuzzy(dot)cz>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: jsonb and nested hstore
Date: 2014-03-12 20:37:39
Message-ID: 5320C593.6070407@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 03/12/2014 04:10 PM, Peter Geoghegan wrote:
> On Wed, Mar 12, 2014 at 11:57 AM, Oleg Bartunov <obartunov(at)gmail(dot)com> wrote:
>> Also, GiST index is faster for create/update operations. I really hope we will
>> improve jsonb indexing in the next one-two releases. For now I'd suggest people
>> index expressional indexes to index just interesting keys or use GiST.
> When do you ever want to index non-interesting keys?
>

The problem is when do you know they are interesting?

One major use case for using treeish data types in the first place is
that you don't know when you're designing the database exactly what
shape the data will be. If you don't know that, then how are you
supposed to know what in it will be interesting? It's somewhat analogous
to full text indexing, where we don't know in advance what phrases or
words will be interesting. Here, a key is the equivalent of a word and a
key path or subpath is the equivalent of a phrase.

Maybe I'm dreaming, since I have no idea how to go about this sort of
indexing, but it's where I'd like to see lots of effort.

I agree with Oleg that we need to be very creative about jsonb indexing.
One of my hopes is that by going down the road we are on, we'll get much
wider interest in this, and that both ideas and money might flow towards
addressing it in a way that we probably wouldn't have seen otherwise.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2014-03-12 20:45:20 Re: Replication slots and footguns
Previous Message Oleg Bartunov 2014-03-12 20:34:52 Re: jsonb and nested hstore