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.
|
Список | 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 по дате отправления: