Re: Disable OpenSSL compression
| От | Bruce Momjian |
|---|---|
| Тема | Re: Disable OpenSSL compression |
| Дата | |
| Msg-id | 201111112011.pABKBgk21858@momjian.us обсуждение исходный текст |
| Ответ на | Re: Disable OpenSSL compression ("Albe Laurenz" <laurenz.albe@wien.gv.at>) |
| Ответы |
Re: Disable OpenSSL compression
|
| Список | pgsql-hackers |
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 remove. This one should never get in > > there to start with. > > I agree that it is sensible to have the setting on the client, > and that there should not be too many GUCs. > > >> 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... > > > > This argument reads as nothing except "I'm too lazy to solve it right, > > so I want you to accept a wrong solution". > > In a way, yes, except that I think that "wrong" is exaggerated. > As DBA I like to have an option to control things from the server > end -- if that's laziness, so be it. > > So, should I forget about the GUC or is anybody going to back me? > > 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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: