Re: libpq compression - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: libpq compression
Date
Msg-id 4FE8CC50.4060707@timbira.com
Whole thread Raw
In response to Re: libpq compression  (Florian Pflug <fgp@phlo.org>)
Responses Re: libpq compression
List pgsql-hackers
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,
Suporte24x7 e Treinamento
 


pgsql-hackers by date:

Previous
From: Satoshi Nagayasu
Date:
Subject: pg_stat_lwlocks view - lwlocks statistics
Next
From: Euler Taveira
Date:
Subject: Re: libpq compression