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
