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?
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
