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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
