Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 9ED3D1927160 for ; Tue, 26 Jun 2012 12:47:59 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SjXzf-0006Ny-9F for pgsql-hackers@postgresql.org; Tue, 26 Jun 2012 15:47:58 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q5QFlV5E007359; Tue, 26 Jun 2012 11:47:31 -0400 (EDT) From: Tom Lane To: Robert Haas cc: "ktm@rice.edu" , Florian Pflug , Dimitri Fontaine , Magnus Hagander , Euler Taveira , Marko Kreen , Martijn van Oosterhout , Bruce Momjian , Pgsql Hackers , Claes Jakobsson Subject: Re: libpq compression In-reply-to: References: <1D8B2B60-F42E-448C-9295-C07FACCF0611@phlo.org> <7760EC03-5B38-4903-AD2D-95F787B1E1ED@phlo.org> <4FE49F7C.9020300@timbira.com> <20120625202523.GN6547@aart.rice.edu> Comments: In-reply-to Robert Haas message dated "Tue, 26 Jun 2012 11:23:14 -0400" Date: Tue, 26 Jun 2012 11:47:30 -0400 Message-ID: <7358.1340725650@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201206/1536 X-Sequence-Number: 210376 Robert Haas writes: > On Mon, Jun 25, 2012 at 4:25 PM, ktm@rice.edu wrote: >> Here is the benchmark list from the Google lz4 page: >> >> Name Ratio C.speed D.speed >> LZ4 (r59) 2.084 330 915 >> LZO 2.05 1x_1 2.038 311 480 >> QuickLZ 1.5 -1 2.233 257 277 >> Snappy 1.0.5 2.024 227 729 >> LZF 2.076 197 465 >> FastLZ 2.030 190 420 >> zlib 1.2.5 -1 2.728 39 195 >> LZ4 HC (r66) 2.712 18 1020 >> zlib 1.2.5 -6 3.095 14 210 >> lz4 absolutely dominates on compression/decompression speed. While fastlz >> is faster than zlib(-1) on compression, lz4 is almost 2X faster still. > At the risk of making everyone laugh at me, has anyone tested pglz? Another point here is that those Google numbers (assuming that they apply to our use-cases, a point not in evidence) utterly fail to make the argument that zlib is not the thing to use. zlib is beating all the others on compression ratio, often by 50%. Before making any comparisons, you have to make some assumptions about what the network speed is ... and unless it's pretty damn fast relative to your CPU speed getting the better compression ratio is going to be more attractive than saving some cycles. regards, tom lane