Обсуждение: Compression

Came across an old announcement for a product called "Mammoth S/JDBC"
that claimed to have "support for compressed connection streams"
[http://archives.postgresql.org/pgsql-announce/2003-04/msg00010.php].

Looking for the product page, I found that "S/JDBC was discontinued as
the Open Source version reached the same capability level "
[http://www.commandprompt.com/products/tips].

That's good news -- but I couldn't find any mention of such a feature
in the documentation [http://jdbc.postgresql.org/documentation/head/]?

Eric Jain wrote:
> Came across an old announcement for a product called "Mammoth S/JDBC"
> that claimed to have "support for compressed connection streams"
> [http://archives.postgresql.org/pgsql-announce/2003-04/msg00010.php].
>
> Looking for the product page, I found that "S/JDBC was discontinued as
> the Open Source version reached the same capability level "
> [http://www.commandprompt.com/products/tips].
>
> That's good news -- but I couldn't find any mention of such a feature
> in the documentation [http://jdbc.postgresql.org/documentation/head/]?

Can you explain what a "compressed connection stream" is? AFAIK, there
is no such thing supported by the standard server. (And there's been a
wire protocol version change since that release announcement, fwiw)

Possibly, you could convince the underlying SSL/TLS provider to
negotiate SSL compression. I don't know the details of how to do that
offhand.

-O

On 2009-09-28, Oliver Jowett <oliver@opencloud.com> wrote:
> Can you explain what a "compressed connection stream" is? AFAIK, there
> is no such thing supported by the standard server. (And there's been a
> wire protocol version change since that release announcement, fwiw)
>
> Possibly, you could convince the underlying SSL/TLS provider to
> negotiate SSL compression. I don't know the details of how to do that
> offhand.

I assume that what they were referring to is the ability to have all
data that is sent between the client and the server compressed (e.g.
with zlib; MySQL: useCompression=true). I'll email them to ask for a
clarification...

On Mon, Sep 28, 2009 at 17:29, Eric Jain <eric.jain@gmail.com> wrote:
> I assume that what they were referring to is the ability to have all
> data that is sent between the client and the server compressed (e.g.
> with zlib; MySQL: useCompression=true). I'll email them to ask for a
> clarification...

So it looks like compression was supported in their commercial version
of PostgreSQL. When it was discontinued, the people working on the
open source version of PostgreSQL apparently didn't see any point in
incorporating the code to support compression, so now there is none
:-(

Eric Jain <eric.jain@gmail.com> writes:
> So it looks like compression was supported in their commercial version
> of PostgreSQL. When it was discontinued, the people working on the
> open source version of PostgreSQL apparently didn't see any point in
> incorporating the code to support compression, so now there is none
> :-(

I seem to remember that that was discussed and the conclusion was that
it was reinventing the wheel --- you could perfectly well use ssl/ssh
compression if you needed it, and you'd want encryption too anyway
in most plausible scenarios where compression makes sense.  (If the
network trip is long enough to justify compression, it's likely not
all secure.)

            regards, tom lane

On Fri, Oct 2, 2009 at 12:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I seem to remember that that was discussed and the conclusion was that
> it was reinventing the wheel --- you could perfectly well use ssl/ssh
> compression if you needed it, and you'd want encryption too anyway
> in most plausible scenarios where compression makes sense.  (If the
> network trip is long enough to justify compression, it's likely not
> all secure.)

VPN?

In any case: Is setting ssl=true alone enough to ensure that
compression is used? Is there a simple way to test whether or not
compression is used?