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?
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
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.
Stephen R. van den Berg.
Expect the unexpected!
In response to
pgsql-hackers by date
|Next:||From: Dave Page||Date: 2009-01-03 10:59:38|
|Subject: Re: reloptions and toast tables|
|Previous:||From: Simon Riggs||Date: 2009-01-03 09:46:30|
|Subject: Re: Significantly larger toast tables on 8.4?|