Re: Got no response last time on setsockopt post, so I thought I would reiterate.

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Monday, June 11, 2007 3:41 PM
> To: Dann Corbit
> Cc: pgsql-hackers(at)postgresql(dot)org; Larry McGhaw
> Subject: Re: [HACKERS] Got no response last time on setsockopt post,
so I
> thought I would reiterate.
>
> "Dann Corbit" <DCorbit(at)connx(dot)com> 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 nearly enough evidence that this is
> a safe change to make.

May I suggest:
http://www-didc.lbl.gov/TCP-tuning/setsockopt.html
http://www.ncsa.uiuc.edu/People/vwelch/net_perf/tcp_windows.html

We test against dozens of operating systems and we have never had a
problem (generally, we use our own tcp/ip network objects for
communication and we only recently figured out why PostgreSQL was
lagging so far behind and patched libPQ ourselves.) Now, it will be
about 2 weeks before our full regressions have run against PostgreSQL on
all of our platforms, but we do adjust the TCP/IP window on all of our
clients and servers and have yet to find one that is unable to either
negotiate a decent size or ignore our request at worst.

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
Windows

And several others