Re: Question: merit / feasibility of compressing frontend

From: Justin Clift <justin(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Doug McNaught <doug(at)wireboard(dot)com>, Bruno Wolff III <bruno(at)wolff(dot)to>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, 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 21:42:37
Message-ID: 3D34934D.55BBBA85@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Tom,

Tom Lane wrote:
>
> Doug McNaught <doug(at)wireboard(dot)com> writes:
> > 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...
>
> Yup. Seems like a more useful exercise would be to lobby the SSL people
> to include compression as an option in SSL connections. That would
> solve the problem not only for PG, but every other application that uses
> SSL ...

We can all see the merits of having a compressed data stream, especially
in those situations where the byte count if more important than a CPU
cost.

However, I'd like to point out that SSL isn't feasible to use in all
situations, so having to enable SSL to gain compression would be a pain.

If someone's willing to put the time into this, then compression without
SSL feels like a good idea. Not everyone uses SSL. Bad network latency
has a very undesirable effect on the establishment of SSL connections,
and this is especially of interest in those cases where people need to
get short "bursty" amounts of SQL data across a connection as fast as
possible. Aka, client using a frontend app to remote databases over a
modem, and not using persistent connections.

Establishment of an individual SSL session using OpenSSL can take over a
second in this case. Not consistently-always, but I had to time it (on
fast hardware too) for a contract recently when deciding on network
layer transports.

Hope this gives some decent food for thought.

:-)

Regards and best wishes,

Justin Clift

> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Beutin 2002-07-16 21:43:41 Re: UPPER
Previous Message Tom Lane 2002-07-16 21:31:05 Re: Question: merit / feasibility of compressing frontend