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.  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Higher TOAST compression.  (decibel <decibel@decibel.org>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: extension facility (was: revised hstore patch)
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: extension facility (was: revised hstore patch)