Re: Significantly larger toast tables on 8.4? - Mailing list pgsql-hackers

From Stephen R. van den Berg
Subject Re: Significantly larger toast tables on 8.4?
Date
Msg-id 20090103104653.GA14952@cuci.nl
Whole thread Raw
In response to Re: Significantly larger toast tables on 8.4?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
>and I'm still pretty worried about the longevity of any knob we put in
>here.  But we might not have a lot of choice.

>It would be fairly easy, I think, to add some reloption fields that
>would let these parameters be controlled on a per-table level.
>Per-column would be much more painful; do we really need that?

+1

Per table sounds fine for now.  Per column would be nice, but can be worked
around if absolutely necessary by splitting tables.

To avoid having to add another parameter later, I *would* suggest to use
something like:

ALTER TABLE mytable SET COMPRESSIONLEVEL = 9;

Where it can range from 0 (= no compression), to 9 (= maximum compression).
The current algorithm could then either be as simplistic as to kick in
anytime COMPRESSIONLEVEL>=1, and not to compress when COMPRESSIONLEVEL==0.
More advanced algorithms and decisions can be implemented later.

Obviously the algorithm should ideally use the one-dimensional knob to
more or less deliver IO-bound (de)compression at level one, and CPU-bound
(de)compression at level nine.

This kind of one-dimensional knob is well understood by many compression
tools and libraries and users, so it'd make sense to provide something similar
to the DBA.
-- 
Sincerely,          Stephen R. van den Berg.

Expect the unexpected!


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Significantly larger toast tables on 8.4?
Next
From: "Dave Page"
Date:
Subject: Re: reloptions and toast tables