Re: Significantly larger toast tables on 8.4?

Поиск
Список
Период
Сортировка
От Stephen R. van den Berg
Тема Re: Significantly larger toast tables on 8.4?
Дата
Msg-id 20090103104653.GA14952@cuci.nl
обсуждение исходный текст
Ответ на Re: Significantly larger toast tables on 8.4?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Significantly larger toast tables on 8.4?
Следующее
От: "Dave Page"
Дата:
Сообщение: Re: reloptions and toast tables