From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> |
Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "James Mansion" <james(at)mansionfamily(dot)plus(dot)com>, pgsql-hackers(at)postgresql(dot)org, "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl>, "Alex Hunsaker" <badalex(at)gmail(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Significantly larger toast tables on 8.4? |
Date: | 2009-01-05 16:55:03 |
Message-ID: | b42b73150901050855v42b9ddd1s7166cecdbf1ee665@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 5, 2009 at 11:45 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Peter Eisentraut escribió:
>> James Mansion wrote:
>>> Peter Eisentraut wrote:
>>>>> c. Are there any well-known pitfalls/objections which would prevent
>>>>> me from
>>>>> changing the algorithm to something more efficient (read: IO-bound)?
>>>>
>>>> copyright licenses and patents
>>>>
>>> Would it be possible to have a plugin facility?
>>
>> Well, before we consider that, we'd probably want to see proof about the
>> effectiveness of other compression methods.
>
> I did some measurements months ago, and it was very clear that libz
> compression was a lot tighter than the PGLZ code.
we have seen amazing results with lzo compression...2-3x faster
compression times with only 10-15% less compression:
There are tons of supporting examples online, for example:
http://mail.jabber.org/pipermail/standards/2005-October/008768.html
I think, if the database is automatically compressing things (which,
IMO, it shouldn't), a low cpu overhead algorithm should be favored.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-05 16:55:46 | Re: pg_dump roles support |
Previous Message | Bruce Momjian | 2009-01-05 16:52:35 | Re: Updates of SE-PostgreSQL 8.4devel patches (r1386) |