Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id B2CC38BCCF1 for ; Thu, 14 Jun 2012 10:32:53 -0300 (ADT) Received: from oproxy8.bluehost.com ([2605:dc00:100:2::a8] helo=oproxy8-pub.bluehost.com) by magus.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1SfAAH-0002sQ-1U for pgsql-hackers@postgresql.org; Thu, 14 Jun 2012 13:32:52 +0000 Received: (qmail 30328 invoked by uid 0); 14 Jun 2012 13:32:27 -0000 Received: from unknown (HELO host159.hostmonster.com) (74.220.207.159) by oproxy8.bluehost.com with SMTP; 14 Jun 2012 13:32:27 -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=Is6ursHSwBooGhnGyAojFlcDYvHwhipyogmChdrZYEc=; b=Ozlr4ePOw0UyBaDQeK0dpn56cnv/WkZlJDNJe4sWkh0IEsLF96KfN56KVlavhxIPcL5e1tQZxa15Lhbu4SbipNjrLxNYIBBx3WszMdOsOdzmWdeGlZ/UZYwgZ/HnfzBa; Received: from [189.31.16.232] (port=60958 helo=[10.3.2.3]) by host159.hostmonster.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SfA9z-0006pS-1s; Thu, 14 Jun 2012 07:32:27 -0600 Message-ID: <4FD9E70B.9040607@timbira.com> Date: Thu, 14 Jun 2012 10:28:43 -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: Tom Lane CC: Pgsql Hackers Subject: Re: libpq compression References: <4FD9698F.2090407@timbira.com> <29853.1339651170@sss.pgh.pa.us> In-Reply-To: <29853.1339651170@sss.pgh.pa.us> 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 189.31.16.232 authed with euler@timbira.com} X-Pg-Spam-Score: -2.0 (--) X-Archive-Number: 201206/630 X-Sequence-Number: 209470 On 14-06-2012 02:19, Tom Lane wrote: > I still think that pushing this off to openssl (not an ssh tunnel, but > the underlying transport library) would be an adequate solution. > If you are shoving data over a connection that is long enough to need > compression, the odds that every bit of it is trustworthy seem pretty > small, so you need encryption too. > I don't want to pay the SSL connection overhead. Also I just want compression, encryption is not required. OpenSSL give us encryption with/without compression; we need an option to obtain compression in non-SSL connections. > We do need the ability to tell openssl to use compression. We don't > need to implement it ourselves, nor to bring a bunch of new library > dependencies into our builds. I especially think that importing bzip2 > is a pretty bad idea --- it's not only a new dependency, but bzip2's > compression versus speed tradeoff is entirely inappropriate for this > use-case. > I see, the idea is that bzip2 would be a compiled-in option (not enabled by default) just to give another compression option. I don't have a strong opinion about including it as another dependency. We already depend on zlib and implementing compression using it won't add another dependency. What do you think about adding a hook at libpq to load an extension that does the compression? That way we don't add another dependency at libpq and also a lot of extensions could be coded to cover a variety of algorithms without putting us in trouble because of patent infringement. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento