Re: Client/Server compression? - Mailing list pgsql-hackers

From Greg Copeland
Subject Re: Client/Server compression?
Date
Msg-id 1016138631.27761.95.camel@mouse.copelandconsulting.net
Whole thread Raw
In response to Re: Client/Server compression?  (Neil Conway <nconway@klamath.dyndns.org>)
List pgsql-hackers
On Thu, 2002-03-14 at 14:14, Neil Conway wrote:
> On Thu, 2002-03-14 at 14:35, Bruce Momjian wrote:
> > Greg Copeland wrote:
> >
> > Checking application/pgp-signature: FAILURE
> > -- Start of PGP signed section.
> > > Well, it occurred to me that if a large result set were to be identified
> > > before transport between a client and server, a significant amount of
> > > bandwidth may be saved by using a moderate level of compression.
> > > Especially with something like result sets, which I tend to believe may
> > > lend it self well toward compression.
> > >
> > > Unlike FTP which may be transferring (and often is) previously
> > > compressed data, raw result sets being transfered between the server and
> > > a remote client, IMOHO, would tend to compress rather well as I doubt
> > > much of it would be true random data.
> >
> > I should have said compressing the HTTP protocol, not FTP.
>
> Except that lots of people compress HTTP traffic (or rather should, if
> they were smart). Bandwidth is much more expensive than CPU time, and
> most browsers have built-in support for gzip-encoded data. Take a look
> at mod_gzip or mod_deflate (2 Apache modules) for more info on this.
>
> IMHO, compressing data would be valuable iff there are lots of people
> with a low-bandwidth link between Postgres and their database clients.
> In my experience, that is rarely the case. For example, people using
> Postgres as a backend for a dynamically generated website usually have
> their database on the same server (for a low-end site), or on a separate
> server connected via 100mbit ethernet to a bunch of webservers. In this
> situation, compressing the data between the database and the webservers
> will just add more latency and increase the load on the database.
>
> Perhaps I'm incorrect though -- are there lots of people using Postgres
> with a slow link between the database server and the clients?
>


What about remote support of these databases where a VPN may not be
available?  In my past experience, this was very common as many
companies do not was to expose their database, even via a VPN to the out
side world, while allowing only modem access.  Not to mention, road
warriors that may need to remotely support their databases may find
value here too.  Would they not?

...I think I'm pretty well coming to the conclusion that it may be of
some value...even if only for a limited number of users.


Greg


pgsql-hackers by date:

Previous
From: Greg Copeland
Date:
Subject: Re: Client/Server compression?
Next
From: Greg Copeland
Date:
Subject: Re: Client/Server compression?