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!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
