Re: jsonb format is pessimal for toast compression

From: Jan Wieck <jan(at)wi3ck(dot)info>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kevin Grittner <kgrittn(at)ymail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, "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-09-05 02:04:40
Message-ID: 54091A38.2030009@wi3ck.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08/12/2014 10:58 AM, Robert Haas wrote:
> What would really be ideal here is if the JSON code could inform the
> toast compression code "this many initial bytes are likely
> incompressible, just pass them through without trying, and then start
> compressing at byte N", where N is the byte following the TOC. But I
> don't know that there's a reasonable way to implement that.
>

Sorry, being late for the party.

Anyhow, this strikes me as a good basic direction of thought. But I
think we should put the burden on the data type, not on toast. To do
that data types could have an optional toast_hint_values() function,
which the toast code can call with the actual datum at hand and its
default parameter array. The hint values function then can modify that
parameter array, telling toast how much to skip, how hard to try (or not
at all) and so on. A data type specific function should know much better
how to figure out how compressible a particular datum may be.

Certainly nothing for 9.4, but it might require changing the toast API
in a different way than just handing it an oid and hard-coding the
JASONBOID case into toast for 9.4. If we are going to change the API, we
might as well do it right.

Regards,
Jan

--
Jan Wieck
Senior Software Engineer
http://slony.info

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2014-09-05 02:24:11 Re: jsonb format is pessimal for toast compression
Previous Message Stephen Frost 2014-09-05 01:53:05 Re: A mechanism securing web applications in DBMS