pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Euler Taveira <euler@timbira.com>
To: Florian Pflug <fgp@phlo.org>
Cc: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Marko Kreen <markokr@gmail.com>
Cc: Martijn van Oosterhout <kleptog@svana.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Cc: Claes Jakobsson <claes@versed.se>
Subject: Re: libpq compression
Date: Mon, 25 Jun 2012 17:38:40 -0300
Message-ID: <4FE8CC50.4060707@timbira.com> (raw)
In-Reply-To: <E52370CE-442F-46CC-BE5F-C7577FFB283F@phlo.org>
References: <CABUevEzVpqS5RCLz2fFREdPFkuYkEKsrMpnfPixYWPki2=iJOA@mail.gmail.com>
	<5365.1339799869@sss.pgh.pa.us>
	<CABUevEz_V4YYc0tUhkC6KD2GddysM5Z76pcHcMYiMDd7dwMxVQ@mail.gmail.com>
	<11357.1339822502@sss.pgh.pa.us>
	<CABUevEy1sUTOeCjNicUggnMpT7MfgjWud8kQ=wkvJsfbCU8=WQ@mail.gmail.com>
	<19804.1339859730@sss.pgh.pa.us>
	<9B10BD6E-31AA-4699-BB67-5C386B623F77@phlo.org>
	<27043.1339950593@sss.pgh.pa.us>
	<20120618174233.GA24681@svana.org>
	<CA+TgmoaTMxcAFMN8d_FXD1S_3keyq3a=Vwa7ka8cnVepy-jqjg@mail.gmail.com>
	<1D8B2B60-F42E-448C-9295-C07FACCF0611@phlo.org>
	<CABUevEybu+v7zcsM8qtOEFdQ95njyK=ERjVbdMAe3c7T2Ut6JA@mail.gmail.com>
	<7760EC03-5B38-4903-AD2D-95F787B1E1ED@phlo.org>
	<CACMqXCLkOpYnK1eLTb_bAqx344C9j=rchTeNXSW=E6+hdXwyPA@mail.gmail.com>
	<4FE49F7C.9020300@timbira.com>
	<CA+Tgmobw1Hhm4ZoS34o4bJBmMtQrnbU17v01+gCMeGmf8e06Fw@mail.gmail.com>
	<CABUevExTHWBAo_9mMUSOieWumQ66WhOao2MpCfdxUgEMYcW0Dw@mail.gmail.com>
	<m2obo719kz.fsf@2ndQua drant.fr>
	<E52370CE-442F-46CC-BE5F-C7577FFB283F@phlo.org>

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



view thread (289+ messages)  latest in thread

Message-ID: <4FE8CC50.4060707@timbira.com>
Permalink:  ../4FE8CC50.4060707@timbira.com/
Also on:    postgresql.org/message-id/4FE8CC50.4060707@timbira.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: euler@timbira.com, fgp@phlo.org, dimitri@2ndQuadrant.fr, magnus@hagander.net, robertmhaas@gmail.com, markokr@gmail.com, kleptog@svana.org, tgl@sss.pgh.pa.us, bruce@momjian.us, claes@versed.se
  Subject: Re: libpq compression
  In-Reply-To: <4FE8CC50.4060707@timbira.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox