Re: Higher TOAST compression.
От | Laurent Laborde |
---|---|
Тема | Re: Higher TOAST compression. |
Дата | |
Msg-id | 8a1bfe660907230422m30415713m24c7d2678b738514@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Higher TOAST compression. (Laurent Laborde <kerdezixe@gmail.com>) |
Ответы |
Re: Higher TOAST compression.
Re: Higher TOAST compression. |
Список | pgsql-hackers |
On Wed, Jul 22, 2009 at 10:54 AM, Laurent Laborde<kerdezixe@gmail.com> wrote: > My 1st applied patch is the safest and simpliest : > in pg_lzcompress.c : > > static const PGLZ_Strategy strategy_default_data = { > 256, /* Data chunks less than 256 are not compressed */ > 256, /* force compression on data chunks on record >= 256bytes */ > 1, /* compression rate below 1% fall back to uncompressed */ > 256, /* Stop history lookup if a match of 256 bytes is found */ > 6 /* lower good match size b 6% at every lookup iteration */ > }; > const PGLZ_Strategy *const PGLZ_strategy_default = &strategy_default_data; I'm testing in production since yesterday. It greatly improved %IOwait. My 1st guess is that postgresql keep more data inline instead of moving it in extern to toast table, reducing massively the IOseek and resulting in a higher IO througput. (iostat show a 5~25MB/s bandwidth at 100%util instead of 2~5MB/s at 100%util). So... now i'm not sure anymore about lowering the tuple per page from 4 to 8. Doing that would mean more data in TOAST table ... -- Laurent "ker2x" Laborde Sysadmin @ http://www.over-blog.com/
В списке pgsql-hackers по дате отправления: