Re: Higher TOAST compression.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Higher TOAST compression.
Дата
Msg-id 8090.1248226329@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Higher TOAST compression.  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Higher TOAST compression.  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Itagaki Takahiro
Дата:
Сообщение: Re: Sampling profiler updated
Следующее
От: Tom Lane
Дата:
Сообщение: Re: generic explain options v3