> -----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 reiterate.
> "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 appears more up-to-date than the other pages, and it
> recommends *against* setting SO_SNDBUF or SO_RCVBUF on modern Linuxen.
> So that's one fairly large category where we probably do not want

It can still be a good idea to set it:
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
> the server-to-client or client-to-server direction, and your
> about the test conditions makes it even harder to know what you are
> measuring.  I would think for instance that local vs remote
> 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
> 8K for about ten years now ...

I suspect that TCP/IP packetizing will moderate the affects of changes
on this parameter.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to