Re: JSONB performance enhancement for 9.6

[Tom Smith <tomsmith1989sk@xxxxxxxxx>]

No, it is within the individual json object storage. In a way, it would be part of query plan,

but strictly for the individual json object storage structure, it is not necessarily an "index"

one possible(but primitive) implementation could be like having multiple "segments" in the storage,

all keys starting with "a"  is in first segment, etc. 

On Sun, May 1, 2016 at 4:14 PM, Oleg Bartunov <obartunov@xxxxxxxxx> wrote:

On Sun, May 1, 2016 at 6:46 AM, Tom Smith <tomsmith1989sk@xxxxxxxxx> wrote:

Hello:

I'd like to bring this JSONB performance issue again.

Below is a link of MySQL way of storing/retrieving Json key/value

https://dev.mysql.com/doc/refman/5.7/en/json.html

Instead of providing column indexing(like GIN for JSONB in Postgresql).

it provides only internal data structure level indexing within each individual json object

for fast retrieval.  compression is not used.

Perhaps without implementing  complicated column level GIN indexing, implementing

a new variant JSON type that only handle  individual json object indexing would be

feasible?  Combined with current JSONB implementation,   both common use cases

(one is global doc indexing, the other is fast retrieval of individual values)

would work out and make postgresql unbeatable.

It's called _expression_ index ?

 

On Tue, Jan 19, 2016 at 8:51 PM, Bruce Momjian <bruce@xxxxxxxxxx> wrote:

On Mon, Jan 11, 2016 at 09:01:03PM -0500, Tom Smith wrote:
> Hi,
>
> Congrats on the official release of 9.5
>
> And I'd like bring up the issue again about if 9.6 would address the jsonb
> performance issue
> with large number of top level keys.
> It is true that it does not have to use JSON format. it is about serialization
> and fast retrieval
> of dynamic tree structure objects. (at top level, it might be called dynamic
> columns)
> So if postgresql can have its own way, that would work out too as long as it
> can have intuitive query
> (like what are implemented for json and jsonb) and fast retrieval of a tree
> like object,
> it can be called no-sql data type. After all, most motivations of using no-sql
> dbs like MongoDB
> is about working with dynamic tree object.
>
> If postgresql can have high performance on this, then many no-sql dbs would
> become history.

I can give you some backstory on this.  TOAST was designed in 2001 as a
way to store, in a data-type-agnostic way, long strings compressed and
any other long data type, e.g. long arrays.

In all previous cases, _part_ of the value wasn't useful.  JSONB is a
unique case because it is one of the few types that can be processed
without reading the entire value, e.g. it has an index.

We are going to be hesitant to do something data-type-specific for
JSONB.  It would be good if we could develop a data-type-agnostic
approach to has TOAST can be improved.  I know of no such work for 9.6,
and it is unlikely it will be done in time for 9.6.

--
  Bruce Momjian  <bruce@xxxxxxxxxx>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription                             +