Re: JSONB performance enhancement for 9.6

From: Tom Smith <tomsmith1989sk(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Arthur Silva <arthurprs(at)gmail(dot)com>, Thomas Kellerer <spam_eater(at)gmx(dot)net>, PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: JSONB performance enhancement for 9.6
Date: 2016-01-12 02:01:03
Message-ID: CAKwSVFE=0eRd4R4vEJcPWtEFa04MQfarnC6DskSqdPssvq+kuw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.

Thanks

On Thu, Dec 3, 2015 at 5:31 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

> On 11/29/15 9:30 AM, Arthur Silva wrote:
>
>> Is this correct? I'm fairly sure jsonb supports lazily parsing objects
>> and each object level is actually searched using binary search.
>>
>
> The problem is there's no support for loading just part of a TOASTed
> field. Even if that existed, we'd still need a way to know what byte
> position in the TOASTed field a key lived at.
>
> It's possible to add all that, but I think it'd be a serious amount of
> work.
>
> Since someone else was just wondering about storing more specific types in
> JSON, it might be more useful/interesting to devise a Postgres-specific way
> to store variable schema documents. That would give us a lot more
> flexibility over implementation than the JSON type ever will.
>
> Or think about it this way: there's really no great reason why everyone
> chose JSON. There's tons of other serialization storage formats for other
> languages out there, so why not one specialized to Postgres? (And of course
> we'd want to be able to cast from that to JSON and back...)
> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message James Keener 2016-01-12 02:09:38 Re: WIP: CoC
Previous Message Michael Paquier 2016-01-12 02:00:51 Re: Building PostgreSQL in Eclipse on Windows