Re: jsonb format is pessimal for toast compression

Jan Wieck <jan@wi3ck.info> writes:
> On 09/15/2014 09:46 PM, Craig Ringer wrote:
>> Anyway - this is looking like the change will go in, and with it a
>> catversion bump. Introduction of a jsonb version/flags byte might be
>> worthwhile at the same time. It seems likely that there'll be more room
>> for improvement in jsonb, possibly even down to using different formats
>> for different data.
>> 
>> Is it worth paying a byte per value to save on possible upgrade pain?

> If there indeed has to be a catversion bump in the process of this, then 
> I agree with Craig.

FWIW, I don't really.  To begin with, it wouldn't be a byte per value,
it'd be four bytes, because we need word-alignment of the jsonb contents
so there's noplace to squeeze in an ID byte for free.  Secondly, as I
wrote in <15378.1408548595@sss.pgh.pa.us>:

: There remains the
: question of whether to take this opportunity to add a version ID to the
: binary format.  I'm not as excited about that idea as I originally was;
: having now studied the code more carefully, I think that any expansion
: would likely happen by adding more type codes and/or commandeering the
: currently-unused high-order bit of JEntrys.  We don't need a version ID
: in the header for that.  Moreover, if we did have such an ID, it would be
: notationally painful to get it to most of the places that might need it.

Heikki's patch would eat up the high-order JEntry bits, but the other
points remain.
        regards, tom lane