Re: Higher TOAST compression.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Laurent Laborde" <kerdezixe(at)gmail(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Higher TOAST compression.
Date: 2009-07-22 01:32:09
Message-ID: 8090.1248226329@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> It seems like it might be reasonable to have a separate threshold for
> compression from that for out-of-line storage. Since I've been in
> that code recently, I would be pretty comfortable doing something
> about that; but, as is so often the case, the problem will probably be
> getting agreement on what would be a good change.

> Ignoring for a moment the fact that "low hanging fruit" in the form of
> *very* large values can be handled first, the options would seem to
> be:

> (1) Just hard-code a lower default threshold for compression than for
> out-of-line storage.

> (2) Add a GUC or two to control thresholds.

> (3) Allow override of the thresholds for individual columns.

I'm not clear how this would work. The toast code is designed around
hitting a target for the overall tuple size; how would it make sense
to treat compression and out-of-lining differently? And especially,
how could you have per-column targets?

I could see having a reloption that allowed per-table adjustment of the
target tuple width...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-22 02:05:30 Re: generic explain options v3
Previous Message Itagaki Takahiro 2009-07-22 01:30:36 Re: Sampling profiler updated