Re: jsonb and nested hstore

On Wed, Mar 12, 2014 at 1:37 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> 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.

You don't know exactly how, but you have some idea. The major benefit
is that you can add new things to new documents as the need arises,
and that's not a big deal, nor does it require a migration with DDL.
If we continue to take MongoDB as representative of how people will
use jsonb, they pretty strongly encourage the idea that you have to
have some structure or design. Google "mongodb schema design" to see
what I mean - you'll find plenty. It has more to do with making
querying the data possible than anything else. There is a limited
amount you can do with a bunch of documents that share little in
common in terms of their structure - what does a query (that can use
an index just in principle) even look like there?

The use case you describe here doesn't sound like something similar to
full text search. It sounds like something identical.

In any case, let's focus on what we have right now. I think that the
indexing facilities proposed here are solid. In any case they do not
preclude working on better indexing strategies as the need emerges.

-- 
Peter Geoghegan