Re: Client/Server compression?

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.
>
> > This may be of value for users with low bandwidth connectivity to their
> > servers or where bandwidth may already be at a premium.
>
> But don't slow links do the compression themselves, like PPP over a
> modem?

Yes, and not really. Modems have very very very small buffers, so the
compression is extremely ineffectual. Link-level compression can be
*highly* effective in making client/server communication snappy, since
faster processors are tending to push the speed bottleneck onto the
wire. We use HTTP Content-Encoding of gzip for our company and the
postgis.refractions.net site, and save about 60% on all the text content
on the wire. For highly redundant data (like result sets) the savings
would be even greater. I have nothing but good things to say about
client/server compression.

--
__
/
| Paul Ramsey
| Refractions Research
| Email: pramsey(at)refractions(dot)net
| Phone: (250) 885-0632
\_