Skip site navigation (1) Skip section navigation (2)

Re: Higher TOAST compression.

From: decibel <decibel(at)decibel(dot)org>
To: Laurent Laborde <kerdezixe(at)gmail(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Higher TOAST compression.
Date: 2009-07-29 17:11:42
Message-ID: 26E64FA5-9CD3-42D2-BEAB-516BC2C3D917@decibel.org (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
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



In response to

pgsql-hackers by date

Next:From: decibelDate: 2009-07-29 17:16:48
Subject: Re: [RFC] new digest datatypes, or generic fixed-len hex types?
Previous:From: Greg StarkDate: 2009-07-29 17:07:16
Subject: Re: date_part()/EXTRACT(second) behaviour with time data type

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group