From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Larry White <ljw1001(at)gmail(dot)com> |
Subject: | Re: jsonb format is pessimal for toast compression |
Date: | 2014-08-08 19:34:07 |
Message-ID: | CAPpHfdvPV4iCqjAK+k4+ZO0X2jN7kUEzPT4y2Pf4c52L=UZQJQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 8, 2014 at 9:14 PM, Teodor Sigaev <teodor(at)sigaev(dot)ru> wrote:
> Curious idea: we could swap JEntry array and values: values in the
>> begining of type will be catched by pg_lzcompress. But we will need to
>> know offset of JEntry array, so header will grow up till 8 bytes
>> (actually, it will be a varlena header!)
>>
>
> May be I wasn't clear:jsonb type will start from string collection instead
> of JEntry array, JEntry array will be placed at the end of object/array.
> so, pg_lzcompress will find repeatable 4-byte pieces in first 1024 bytes of
> jsonb.
Another idea I have is that store offset in each JEntry is not necessary to
have benefit of binary search. Namely what if we store offsets in each 8th
JEntry and length in others? The speed of binary search will be about the
same: overhead is only calculation offsets in the 8-entries chunk. But
lengths will probably repeat.
------
With best regards,
Alexander Korotkov.
From | Date | Subject | |
---|---|---|---|
Next Message | Ants Aasma | 2014-08-08 19:41:20 | Re: jsonb format is pessimal for toast compression |
Previous Message | Pavel Stehule | 2014-08-08 19:16:23 | Re: psql: show only failed queries |