Robert Haas <robertmh...@gmail.com> writes: > On Thu, Oct 6, 2016 at 9:46 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Can anyone think of a test case that would stress semaphore operations >> more heavily, without being unrealistic?
> I think it's going to be pretty hard to come up with a non-artificial > test case that has exhibits meaningful lwlock contention on an 8-core > system. If you go back to 9.1, before we had fast-path locking, you > can do it, because the relation locks and vxid locks do cause > noticeable contention on the lock manager locks in that version. > ... > Alternatively, get a bigger box. :-) Well, I did both of the above. I tried 9.1 on "hydra", that 60-processor POWER7 box, and cranked the parallelism up to ridiculous levels: pgbench -S -j 250 -c 250 -M prepared -T 60 bench Median of 3 runs with sysv semaphores: number of transactions actually processed: 1554570 tps = 25875.432836 (including connections establishing) tps = 25894.938187 (excluding connections establishing) Ditto, for unnamed POSIX semaphores: number of transactions actually processed: 1726696 tps = 28742.486104 (including connections establishing) tps = 28765.963071 (excluding connections establishing) That's about a 10% win for POSIX semaphores. Now, at saner loads, I couldn't see much of any difference between the two semaphore APIs. So I'm still of the opinion that there's not likely to be any meaningful performance difference in practice, at least not on reasonably recent Linux machines. But this does indicate that if there is any difference, it will probably favor switching. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers