Re: jsonb format is pessimal for toast compression

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <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-11 20:00:51
Message-ID: 28720.1407787251@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> What we could conceivably do now is (a) add a datatype OID argument to
>> toast_compress_datum, and (b) hard-wire the selection of a different
>> compression-parameters struct if it's JSONBOID. The actual fix would
>> then be to increase the first_success_by field of this alternate struct.

> Isn't the offset-to-compressable-data variable though, depending on the
> number of keys, etc? Would we be increasing first_success_by based off
> of some function which inspects the object?

Given that this is a short-term hack, I'd be satisfied with setting it
to INT_MAX.

If we got more ambitious, we could consider improving the cutoff logic
so that it gives up at "x% of the object or n bytes, whichever comes
first"; but I'd want to see some hard evidence that that was useful
before adding any more cycles to pglz_compress.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-08-11 20:01:24 Re: jsonb format is pessimal for toast compression
Previous Message Stephen Frost 2014-08-11 19:53:41 Re: jsonb format is pessimal for toast compression