Re: JSONB performance enhancement for 9.6

Поиск
Список
Период
Сортировка
От Tom Smith
Тема Re: JSONB performance enhancement for 9.6
Дата
Msg-id CAKwSVFE=0eRd4R4vEJcPWtEFa04MQfarnC6DskSqdPssvq+kuw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: JSONB performance enhancement for 9.6  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: JSONB performance enhancement for 9.6  (Bruce Momjian <bruce@momjian.us>)
Список 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.Nasby@bluetreble.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

В списке pgsql-general по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Building PostgreSQL in Eclipse on Windows
Следующее
От: James Keener
Дата:
Сообщение: Re: WIP: CoC