> -----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 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. ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq