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-20 16:15:07 |
Message-ID: | 8a1bfe660907200915r53f94b6bwb9434f6088ab770b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 20, 2009 at 6:04 PM, Kevin
Grittner<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>
>> What about setting "PGLZ_strategy_always" as the default strategy
>> (insane cpu cost ?) ?
>> Or something in-between ?
>
> That goes beyond what I was trying to do with my recent patch. What
> you propose may be useful, but there would need to be much discussion
> and benchmarking and it would be a new patch.
>
> If you have any benchmark information on relative speed and space
> savings, please post them.
I will try that as soon as my spare production server (2x4core Xeon,
32GB RAM, 8 SAS Disk) is back to life.
I wasn't thinking about the very aggressive (strategy_always)
compression strategy for a default postgresql release.
Not everyone is IObound :)
But just as a default setting here at over-blog. (definitively IOBound
with large articles and comment).
Anyway, i will try and report different strategy here.
Thank you again for your feedback.
--
Laurent Laborde
Sysadmin @ http://www.over-blog.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-07-20 16:20:41 | Re: Review: Revise parallel pg_restore's scheduling heuristic |
Previous Message | Kevin Grittner | 2009-07-20 16:04:41 | Re: Higher TOAST compression. |