From: | Doug McNaught <doug(at)wireboard(dot)com> |
---|---|
To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Chris Albertson <chrisalbertson90278(at)yahoo(dot)com>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Question: merit / feasibility of compressing frontend |
Date: | 2002-07-16 16:13:14 |
Message-ID: | m3k7nvy7l1.fsf@varsoon.wireboard.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bruno Wolff III <bruno(at)wolff(dot)to> writes:
> On Tue, Jul 16, 2002 at 01:59:10 -0700,
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote:
> >
> > 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).
>
> Shouldn't the VPN be doing compression?
Most VPNs (eg ones based on IPsec) work at the IP packet level, with
no knowledge of the streams at higher levels. I don't think the IPsec
standard addresses compression at all--that's supposed to be handled
at the link layer (eg PPP) or at higher levels.
Even if it were there, packet-by-packet compression, or that provided
by a 56K modem link, isn't going to give you nearly as big a win as
compressing at the TCP stream level, where there is much more
redundancy to take advantage of, and you don't have things like packet
headers polluting the compression dictionary.
I'm not advocating zlib-in-PG, but it does seem that some people would
find it useful.
-Doug
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-07-16 16:15:44 | Re: OIDs (Or: another RTFM question?) |
Previous Message | Bruce Momjian | 2002-07-16 16:13:07 | Re: brk() function and performance |