> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 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 reiterate.
>
> "Dann Corbit" <DCorbit@connx.com> 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 appears more up-to-date than the other pages, and it
specifically
> recommends *against* setting SO_SNDBUF or SO_RCVBUF on modern Linuxen.
> So that's one fairly large category where we probably do not want
this.
It can still be a good idea to set it:
http://datatag.web.cern.ch/datatag/howto/tcp.html
64K was just an example. Like I said before, it should be configurable.
> You have not even made it clear whether you were increasing the sizes
in
> the server-to-client or client-to-server direction, and your
handwaving
> about the test conditions makes it even harder to know what you are
> measuring. I would think for instance that local vs remote
connections
> make a big difference and might need different tuning.
The configuration is a negotiation between client and server. You may
or may not get what you ask for. I suggest that it is simple to
implement and worthwhile to test. But it was only a suggestion.
> BTW, if we look at this issue we ought to also look at whether the
> send/recv quantum in libpq and the backend should be changed. It's
been
> 8K for about ten years now ...
I suspect that TCP/IP packetizing will moderate the affects of changes
on this parameter.