Re: Got no response last time on setsockopt post, so I thought I would reiterate. - Mailing list pgsql-hackers

From Dann Corbit
Subject Re: Got no response last time on setsockopt post, so I thought I would reiterate.
Date
Msg-id D425483C2C5C9F49B5B7A41F8944154701000720@postal.corporate.connx.com
Whole thread Raw
In response to Re: Got no response last time on setsockopt post, so I thought I would reiterate.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> -----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.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Selecting a constant question
Next
From: "Dann Corbit"
Date:
Subject: Re: Selecting a constant question