Re: Question: merit / feasibility of compressing frontend

Bruno Wolff III <bruno(at)wolff(dot)to> writes:

> 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.

True enough, but my point below still stands--it just makes a lot more
sense to do it up at the stream level, if you have one.

> > 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.

SSH with compression enabled works fairly well for this, but the OP
didn't see the point of using it when he already had a VPN going.

The idea of a generic "compression tunnel" (without the SSH overhead)
is nice, but I've never seen one. Wouldn't be that hard to write, I'd
think.

I think the big obstacle to putting compression into PG is needing to
extend the FE/BE protocol for negotiating compression, and the possible
client compatibility issues that raises. We already have SSL
negotiation working, though...

-Doug