Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id E8D412B286A for ; Mon, 25 Jun 2012 17:42:48 -0300 (ADT) Received: from oproxy1-pub.bluehost.com ([66.147.249.253]) by makus.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1SjG7T-0001lz-IB for pgsql-hackers@postgresql.org; Mon, 25 Jun 2012 20:42:48 +0000 Received: (qmail 13144 invoked by uid 0); 25 Jun 2012 20:42:33 -0000 Received: from unknown (HELO host159.hostmonster.com) (74.220.207.159) by oproxy1.bluehost.com with SMTP; 25 Jun 2012 20:42:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=timbira.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=dmW49VwHwg4xKV8Md+tJ9c6Y4FXlMDHSqibd8UG3bQE=; b=mGtBiK0mk5VnkUUO2Zlv8lT+rdtnJfaQR3QNKARhPVT1047gxqIuJo/hmclUfet8q/3vrDQDz7miR9CbS0FzNXc5nwnCZImnyhKxsocW8ihhrCUZrABkXqxOX8Cro8yK; Received: from [187.55.150.62] (port=61449 helo=[10.3.2.3]) by host159.hostmonster.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SjG7F-0003I3-Ez; Mon, 25 Jun 2012 14:42:33 -0600 Message-ID: <4FE8CC50.4060707@timbira.com> Date: Mon, 25 Jun 2012 17:38:40 -0300 From: Euler Taveira User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Florian Pflug CC: Dimitri Fontaine , Magnus Hagander , Robert Haas , Marko Kreen , Martijn van Oosterhout , Tom Lane , Bruce Momjian , Pgsql Hackers , Claes Jakobsson Subject: Re: libpq compression References: <5365.1339799869@sss.pgh.pa.us> <11357.1339822502@sss.pgh.pa.us> <19804.1339859730@sss.pgh.pa.us> <9B10BD6E-31AA-4699-BB67-5C386B623F77@phlo.org> <27043.1339950593@sss.pgh.pa.us> <20120618174233.GA24681@svana.org> <1D8B2B60-F42E-448C-9295-C07FACCF0611@phlo.org> <7760EC03-5B38-4903-AD2D-95F787B1E1ED@phlo.org> <4FE49F7C.9020300@timbira.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1651:host159.hostmonster.com:timbirac:timbira.com} {sentby:smtp auth 187.55.150.62 authed with euler@timbira.com} X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201206/1490 X-Sequence-Number: 210330 On 25-06-2012 16:45, Florian Pflug wrote: > Agreed. If we extend the protocol to support compression, and not rely > on SSL, then let's pick one of these LZ77-style compressors, and let's > integrate it into our tree. > If we have an option to have it out of our tree, good; if not, let's integrate it. I, particularly, don't see a compelling reason to integrate compression code in our tree, I mean, if we want to support more than one algorithm, it is clear that the overhead for maintain the compression code is too high (a lot of my-new-compression-algorithms). > We should then also make it possible to enable compression only for > the server -> client direction. Since those types of compressions are > usually pretty easy to decompress, that reduces the amount to work > non-libpq clients have to put in to take advantage of compression. > I don't buy this idea. My use case (data load) will not be covered if we only enable server -> client compression. I figure that there are use cases for server -> client compression (replication, for example) but also there are important use cases for client -> server (data load, for example). If you implement decompression, why not code compression code too? -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento