Re: jsonb format is pessimal for toast compression

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: jsonb format is pessimal for toast compression
Дата
Msg-id 11631.1407514801@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: jsonb format is pessimal for toast compression  (John W Higgins <wishdev@gmail.com>)
Список pgsql-hackers
John W Higgins <wishdev@gmail.com> writes:
> Would an answer be to switch the location of the jsonb "header" data to the
> end of the field as opposed to the beginning of the field? That would allow
> pglz to see what it wants to see early on and go to work when possible?

Hm, might work.  Seems a bit odd, but it would make pglz_compress happier.

OTOH, the big-picture issue here is that jsonb is generating
noncompressible data in the first place.  Putting it somewhere else in the
Datum doesn't change the fact that we're going to have bloated storage,
even if we dodge the early-exit problem.  (I suspect the compression
disadvantage vs text/plain-json that I showed yesterday is coming largely
from that offset array.)  But I don't currently see how to avoid that and
still preserve the fast binary-search key lookup property, which is surely
a nice thing to have.
        regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Defining a foreign key with a duplicate column is broken
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: jsonb format is pessimal for toast compression