On Jul 23, 2009, at 6:22 AM, Laurent Laborde wrote:
On Wed, Jul 22, 2009 at 10:54 AM, Laurent
Laborde<kerdez...@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 ...
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 deci...@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
