On Jul 23, 2009, at 6:22 AM, Laurent Laborde wrote:
> 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 ...
What's the typical size of your data that's being toasted? I actually
have a number of cases where I'd like to push data into external
storage, because it seriously hurts tuple density (and I doubt it'd
compress well).
--
Decibel!, aka Jim C. Nasby, Database Architect decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828