On Mon, Jan 5, 2009 at 11:45 AM, Alvaro Herrera <alvhe...@commandprompt.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
