I wrote: > At -j 10 -c 10, all else the same, I get 84928 TPS on HEAD and 90357 > with the patch, so about 6% better.
And at -j 1 -c 1, I get 22390 and 24040 TPS, or about 7% better with the patch. So what I am seeing on OS X isn't contention of any sort, but just a straight speedup that's independent of the number of clients (at least up to 10). Probably this represents less setup/teardown cost for kqueue() waits than poll() waits. So you could spin this as "FreeBSD's poll() implementation is better than OS X's", or as "FreeBSD's kqueue() implementation is worse than OS X's", but either way I do not think we're seeing the same issue that was originally reported against Linux, where there was no visible problem at all till you got to a couple dozen clients, cf https://www.postgresql.org/message-id/CAB-SwXbPmfpgL6N4Ro4BbGyqXEqqzx56intHHBCfvpbFUx1DNA%40mail.gmail.com I'm inclined to think the kqueue patch is worth applying just on the grounds that it makes things better on OS X and doesn't seem to hurt on FreeBSD. Whether anyone would ever get to the point of seeing intra-kernel contention on these platforms is hard to predict, but we'd be ahead of the curve if so. It would be good for someone else to reproduce my results though. For one thing, 5%-ish is not that far above the noise level; maybe what I'm measuring here is just good luck from relocation of critical loops into more cache-line-friendly locations. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers