On Thu, Nov 17, 2011 at 10:11, Albe Laurenz wrote:
> I wrote:
>> Here it is. I'll add it to the November commitfest.
>
> Here is the second version.
>
> I realized that it is better to set the option on the SSL object
> and not on the SSL context so that it is possible to change it
> per connectio
I wrote:
> Here it is. I'll add it to the November commitfest.
Here is the second version.
I realized that it is better to set the option on the SSL object
and not on the SSL context so that it is possible to change it
per connection.
I also improved the documentation.
Yours,
Laurenz Albe
ssl
Bruce Momjian wrote:
>> I'd still be willing to write a patch for a client-only solution.
>
> Agreed. There is clearly a win in turning off SSL compression for
> certain workloads, and if people think the client is the right
location,
> then let's do it there.
Here it is. I'll add it to the Nove
Albe Laurenz wrote:
> Tom Lane wrote:
> > But in any case, my objection is that there's no adequate use-case
> > for this GUC, because it's much more sensible to set it from the
> client
> > side. We have too many GUCs already --- Josh B regularly goes on the
> > warpath looking for ones we can re
Tom Lane wrote:
> But in any case, my objection is that there's no adequate use-case
> for this GUC, because it's much more sensible to set it from the
client
> side. We have too many GUCs already --- Josh B regularly goes on the
> warpath looking for ones we can remove. This one should never get
Bruce Momjian writes:
> Tom Lane wrote:
>> Huh? You put it in the connection string, typically. This is not
>> different from how you'd specify sslmode to start with.
> Well, you are saying the client is more flexible, but if the client is a
> binary, it isn't flexible without an environment va
Tom Lane wrote:
> Bruce Momjian writes:
> > How is the compression connection parameter set? It seems odd for it to
> > be compiled into the application because the application could be run on
> > different networks. I don't know of any way to inject connection
> > options from outside the appli
Bruce Momjian writes:
> How is the compression connection parameter set? It seems odd for it to
> be compiled into the application because the application could be run on
> different networks. I don't know of any way to inject connection
> options from outside the application like libpq's PGOPTI
Tom Lane wrote:
> "Albe Laurenz" writes:
> > Tom Lane wrote:
> >> A GUC is entirely, completely, 100% the wrong answer. It has no way
> >> to deal with the fact that some clients may need compression and others
> >> not.
>
> > You can force a certain SSL cipher on the client, why not a compressi
On Thu, Nov 10, 2011 at 5:18 PM, Albe Laurenz wrote:
> I could go and try to convince Npgsql and JDBC to accept patches to
> do that on the client side, but that would be more effort than I
> want to invest. But then there's still closed source software like
> Devart dotConnect...
Are you certai
On Thu, Nov 10, 2011 at 11:01 AM, Tom Lane wrote:
> But in any case, my objection is that there's no adequate use-case
> for this GUC, because it's much more sensible to set it from the client
> side. We have too many GUCs already --- Josh B regularly goes on the
> warpath looking for ones we can
"Albe Laurenz" writes:
> Tom Lane wrote:
>> A GUC is entirely, completely, 100% the wrong answer. It has no way
>> to deal with the fact that some clients may need compression and others
>> not.
> You can force a certain SSL cipher on the client, why not a compression
> setting?
To my mind, the
Tom Lane wrote:
>>> Is the following proposal acceptable:
>>>
>>> - Add a GUC ssl_compression, defaulting to "on".
>>> - Add a client option "sslcompression" and an environment variable
>>> PGSSLCOMPRESSION, defaulting to "1".
> A GUC is entirely, completely, 100% the wrong answer. It has no way
On Thursday, November 10, 2011, Andrew Dunstan wrote:
>
>
> On 11/08/2011 12:39 PM, Tom Lane wrote:
>
>> Jeroen Vermeulen writes:
>>
>>> Another reason why I believe compression is often used with encryption
>>> is to maximize information content per byte of data: harder to guess,
>>> harder to c
On 11/08/2011 12:39 PM, Tom Lane wrote:
Jeroen Vermeulen writes:
Another reason why I believe compression is often used with encryption
is to maximize information content per byte of data: harder to guess,
harder to crack. Would that matter?
Yes, it would. There's a reason why the OpenSSL
Magnus Hagander wrote:
>> Is the following proposal acceptable:
>>
>> - Add a GUC ssl_compression, defaulting to "on".
>> - Add a client option "sslcompression" and an environment variable
>> PGSSLCOMPRESSION, defaulting to "1".
>
> Seems like the reasonable thing, yes.
>
>> Compression will be
On Wed, Nov 09, 2011 at 05:26:14PM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > On Wednesday, November 9, 2011, Albe Laurenz wrote:
> >> Is the following proposal acceptable:
> >>
> >> - Add a GUC ssl_compression, defaulting to "on".
> >> - Add a client option "sslcompression" and an envi
Magnus Hagander writes:
> On Wednesday, November 9, 2011, Albe Laurenz wrote:
>> Is the following proposal acceptable:
>>
>> - Add a GUC ssl_compression, defaulting to "on".
>> - Add a client option "sslcompression" and an environment variable
>> PGSSLCOMPRESSION, defaulting to "1".
> Seems like
On Wednesday, November 9, 2011, Albe Laurenz wrote:
> Christopher Browne wrote:
> >> I think that JDBC and Npgsql should also support disabling
> compression.
> >
> > That's the *real* problem here...
> >
> > You're quite right that if we allow controlling this on the libpq
> > side, it is surely
Christopher Browne wrote:
>> I think that JDBC and Npgsql should also support disabling
compression.
>
> That's the *real* problem here...
>
> You're quite right that if we allow controlling this on the libpq
> side, it is surely desirable to allow controlling this via JDBC,
> Npgsql, and other me
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> The fact of the matter is that in most situations where you want SSL,
> ie links across insecure WANs, compression is a win. Testing a local
> connection, as you seem to have done, is just about 100% irrelevant to
> performance in the real world.
I'm
Jeroen Vermeulen writes:
> Another reason why I believe compression is often used with encryption
> is to maximize information content per byte of data: harder to guess,
> harder to crack. Would that matter?
Yes, it would. There's a reason why the OpenSSL default is what it is.
On 2011-11-08 22:59, Albe Laurenz wrote:
In addition to the oprofile data I collected three times:
- the duration as shown in the server log
- the duration as shown by \timing
- the duration of the psql command as measured by "time"
[...]
I think this makes a good case for disabling compress
On Tue, Nov 8, 2011 at 11:06 AM, k...@rice.edu wrote:
> I think that JDBC and Npgsql should also support disabling compression.
That's the *real* problem here...
You're quite right that if we allow controlling this on the libpq
side, it is surely desirable to allow controlling this via JDBC,
Npg
On Tue, Nov 08, 2011 at 04:19:02PM +0100, Albe Laurenz wrote:
> Tom Lane wrote:
> > I distinctly recall us getting bashed a few years ago because there
> > wasn't any convenient way to turn SSL compression *on*. Now that SSL
> > finally does the sane thing by default, you want to turn it off?
> >
On Tue, Nov 08, 2011 at 04:59:02PM +0100, Albe Laurenz wrote:
> Tom Lane wrote:
> > There might be some argument for providing a client option to disable
> > compression, but it should not be forced, and it shouldn't even be the
> > default. But before adding YA connection option, I'd want to see
Tom Lane wrote:
> There might be some argument for providing a client option to disable
> compression, but it should not be forced, and it shouldn't even be the
> default. But before adding YA connection option, I'd want to see some
> evidence that it's useful over non-local connections.
Here are
Tom Lane wrote:
> I distinctly recall us getting bashed a few years ago because there
> wasn't any convenient way to turn SSL compression *on*. Now that SSL
> finally does the sane thing by default, you want to turn it off?
>
> The fact of the matter is that in most situations where you want SSL,
On Tue, Nov 8, 2011 at 4:34 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz wrote:
>>> It is possible that this could cause a performance
>>> regression for people who SELECT lots of compressible
>>> data over really slow network connections, but is that
On Tue, Nov 8, 2011 at 9:58 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 11/08/2011 09:34 AM, Tom Lane wrote:
>>> There might be some argument for providing a client option to disable
>>> compression, but it should not be forced, and it shouldn't even be the
>>> default. But before adding
Andrew Dunstan writes:
> On 11/08/2011 09:34 AM, Tom Lane wrote:
>> There might be some argument for providing a client option to disable
>> compression, but it should not be forced, and it shouldn't even be the
>> default. But before adding YA connection option, I'd want to see some
>> evidence
On 11/08/2011 09:34 AM, Tom Lane wrote:
Marko Kreen writes:
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz wrote:
It is possible that this could cause a performance
regression for people who SELECT lots of compressible
data over really slow network connections, but is that
a realistic scenari
On Tue, Nov 8, 2011 at 2:34 PM, Tom Lane wrote:
>
> The fact of the matter is that in most situations where you want SSL,
> ie links across insecure WANs, compression is a win. Testing a local
> connection, as you seem to have done, is just about 100% irrelevant to
> performance in the real world
Marko Kreen writes:
> On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz wrote:
>> It is possible that this could cause a performance
>> regression for people who SELECT lots of compressible
>> data over really slow network connections, but is that
>> a realistic scenario?
> Yes, it's a realistic scen
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz wrote:
> It is possible that this could cause a performance
> regression for people who SELECT lots of compressible
> data over really slow network connections, but is that
> a realistic scenario?
Yes, it's a realistic scenario. Please make it a optio
On 11/08/2011 03:59 PM, Albe Laurenz wrote:
> If there are concerns about that, maybe a GUC variable like
> ssl_compression (defaulting to off) would be a solution.
>
I'd vote for a libpq connect option instead. Something like
sslcompress=yes|no accompanied by PGSSLCOMPRESS environment
variable.
On Tue, Nov 8, 2011 at 14:59, Albe Laurenz wrote:
> I ran into a performance problem described in this thread:
>
> http://archives.postgresql.org/pgsql-performance/2011-10/msg00249.php
> continued here:
> http://archives.postgresql.org/pgsql-performance/2011-11/msg00045.php
>
> OpenSSL compresses
I ran into a performance problem described in this thread:
http://archives.postgresql.org/pgsql-performance/2011-10/msg00249.php
continued here:
http://archives.postgresql.org/pgsql-performance/2011-11/msg00045.php
OpenSSL compresses data by default, and that causes a
performance penalty of 100%
38 matches
Mail list logo
