Re: Question: merit / feasibility of compressing frontend

Hello,

All due respect Tom, I am not asking you to. We (CMD) have specific
instances of projects that will require this feature. I have also spoke
with others that have requested that we do something like this for their
projects, although we will not benefit from them. This is why I have
authorized my programmer to implement the feature.

We see a benefit, in compressing result sets for transfer to clients. In
a lot of instances it would take less time to compress and decompress a
result set, than to actually transfer the result set across the wire in
plain text.

If you are dealing with 1 meg of text, across a distributed application
where the client connect via a VPN at 56k, we are talking 4 minutes. If we
compress and send it across that could be 30 seconds (mileage will vary).

Besides, we are not asking the PostgreSQL team to implement the feature,
just to help us understand the existing code a little better (which I
realize now, my budding programmer did not word very well), so that we may
implement it within our code base.

Sincerely,

Joshua D. Drake

We are not asking the PostgreSQL team to do so.

On Tue, 16 Jul 2002, Tom Lane wrote:

> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> > There is a real commercial need, when dealing with VPN's, remote
> > users, and web based distributed applications for something like this.
>
> This unsubstantiated opinion doesn't really do much to change my
> opinion. We have seen maybe two or three prior requests for compression
> (which does not qualify as a groundswell); furthermore they were all "it
> would be nice if..." handwaving, with no backup data to convince anyone
> that any real performance gain would emerge in common scenarios. So I'm
> less than eager to buy into the portability and interoperability
> pitfalls that are likely to emerge from requiring clients and servers to
> have zlib.
>
> regards, tom lane
>