Doug McNaught <doug@wireboard.com> writes:
>> On Thu, Jan 25, 2001 at 11:07:19PM -0500, Tom Lane wrote:
> On a properly designed kernel, there shouldn't be any measurable
> performance difference between a local TCP connection and a Unix-socket
> connection.
> Much as I hesitate to contradict Tom here, I think I need to qualify
> his statement.
> For a localhost TCP socket, a write() has to be sent down the network
> stack and (possibly) split into packets, which are then sent through
> the routing engine and back up through the stack, flow-controlled,
> reassembled, and submitted to the receiving socket. Also, ACK packets
> have to be sent back to the sender through the same tortuous path.
My notion of a "properly designed" kernel is one that has a shortcircuit
path for local TCP connections, to avoid precisely that overhead. Not
all do ... but any kernel wherein attention has been paid to X Windows
performance (to mention just one important case) does.
For example, doing a COPY OUT of about 10MB of data, I get numbers
like this:
$ time psql -h localhost -c "copy foo to stdout" regression >/dev/null
real 0m29.05s
user 0m1.40s
sys 0m0.12s
$ time psql -c "copy foo to stdout" regression >/dev/null
real 0m28.97s
user 0m1.39s
sys 0m0.10s
which is the same to within experimental error, considering there are
background daemons &etc on this machine (an HP-PA box running HPUX
10.20).
Of course, since the kernel is certainly capable of net socket
throughput well in excess of 0.3 megabytes/sec on this machine, this
example really just proves Doug's other point: the difference between a
Unix socket and a TCP socket is unlikely to be important for Postgres
purposes, because it'll be swamped by other factors.
regards, tom lane
