| From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
|---|---|
| To: | Doug McNaught <doug(at)wireboard(dot)com> |
| 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 18:46:26 |
| Message-ID: | 20020716184626.GA32419@wolff.to |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Jul 16, 2002 at 12:13:14 -0400,
Doug McNaught <doug(at)wireboard(dot)com> wrote:
>
> 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.
That can't be right. Once the data is encrypted, you won't be able to
compress it. That is why it is useful for the VPN software to be able
to do it.
> 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.
Maybe a generic compression tool could be put into the path without having
to change either Postgres or your VPN software.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruno Wolff III | 2002-07-16 18:48:42 | Re: User's management |
| Previous Message | Andrew Sullivan | 2002-07-16 18:39:17 | Re: PostgreSQL in mission-critical system |