On Mon, Jul 15, 2002 at 12:01:03PM -0700, pgsql-general wrote:
> As one of my first projects I'm been asked to compress with zlib
> (www.gzip.org/zlib ) data flowing from postgres clients to and
> especially from the backend server. Our first idea was to write a sort
> of 'compression proxy' with a frontend and backend of its own. The
> postgres client would connect to the compression frontend on their local
> machine which would compress and transfer to the compresss backend on
> the server. Decompressed requests would be forwared to the postgres
> server. This idea was abandoned since: 1.) it means existing clients
> would have to be reconfigured to talk to their local machine, and 2.) it
> destroys host based authentication since all packets arriving at the
> sever would be from the local decompressor.
It also strikes me as inefficient and unnecessarily complicated.
> My questions are: Is there any merit to this idea? i.e would
> compressing large result sets decrease the transfer time?
I'm not too keen about it (as was Tom Lane when someone suggested it
earlier, IIRC). The vast majority of PostgreSQL installations place
both the clients and the RDBMS on the same LAN, so I'd expect
that few people would find it useful. And among those that would,
you can get that functionality in other ways (e.g. ssh forwarding,
a generic zlib tunnel if one exists -- similar to stunnel for SSL),
without needing to bloat PostgreSQL.
> How easy or difficult would it be to incorporate such change into the
> postgres frontend and backend source?
Doesn't seem like it would be very difficult, IMHO.
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
