> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 5:12 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org; Larry McGhaw
> Subject: Re: [HACKERS] Got no response last time on setsockopt post,
so I
> thought I would
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> May I suggest:
> http://www-didc.lbl.gov/TCP-tuning/setsockopt.html
> http://www.ncsa.uiuc.edu/People/vwelch/net_perf/tcp_windows.html
I poked around on those pages and almost immediately came across
http://www.psc.edu/networking/projects/tcptune/
which
> -Original Message-
> From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 4:35 PM
> To: Dann Corbit
> Cc: Tom Lane; pgsql-hackers@postgresql.org; Larry McGhaw
> Subject: Re: [HACKERS] Got no response last time on setsockopt post,
so I
> thou
Dann Corbit wrote:
However, I won't twist your arm. I just wanted to be sure that those at
the PostgreSQL organization were aware of this simple trick. Our
products run on:
Aix
BeOS
Hpux
Linux (everywhere, including mainframe zLinux)
MVS
SunOS
Solaris
OpenVMS Alpha
OpenVMS VAX
OpenVMS Itanium
> -Original Message-
> From: Greg Smith [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 4:09 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Got no response last time on setsockopt post,
so I
> thought I would reiterate.
>
On Mon, 11 Jun 2007, Dann Corbit wrote:
These two calls make our remote queries via libpq about twice as fast on
average.
Can you comment a bit on what your remote queries are typically doing?
You'll need to provide at least an idea what type of test case you're
seeing the improvement on for
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 3:41 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org; Larry McGhaw
> Subject: Re: [HACKERS] Got no response last time on setsockopt post,
so I
> thought I would
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> These two calls make our remote queries via libpq about twice as fast on
> average.
And, perhaps, cause even greater factors of degradation in other
scenarios (not to mention the possibility of complete failure on some
platforms). You haven't provided n
These two calls make our remote queries via libpq about twice as fast on
average. It seems to me like it might be a nice addition to the core
product's libpq (I poked it into the spot where the Nagle algorithm is
turned off, but another place would be fine too). Can anyone give me a
reason why it
