From: | Laurent Laborde <kerdezixe(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Higher TOAST compression. |
Date: | 2009-07-23 11:22:59 |
Message-ID: | 8a1bfe660907230422m30415713m24c7d2678b738514@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 22, 2009 at 10:54 AM, Laurent Laborde<kerdezixe(at)gmail(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2009-07-23 11:49:02 | Re: extension facility (was: revised hstore patch) |
Previous Message | Robert Haas | 2009-07-23 11:08:57 | Re: extension facility (was: revised hstore patch) |