Re: spinlock->pthread_mutex : real world results

Nils Goroll <slink@schokola.de>

From: Nils Goroll <slink@schokola.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Martijn van Oosterhout <kleptog@svana.org>, Merlin Moncure <mmoncure@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-08-06T22:10:02Z
Lists: pgsql-hackers
Robert,

> 1. How much we're paying for this in the uncontended case?

Using glibc, we have the overhead of an additional library function call, which 
we could eliminate by pulling in the code from glibc/nptl or a source of other 
proven reference code.

The pgbench results I had posted before 
http://archives.postgresql.org/pgsql-hackers/2012-07/msg00061.php could give an 
indication on the higher base cost for the simple approach.


I have mentioned this before: While I agree that minimizing the base overhead is 
good, IMHO, optimizing the worst case is the important part here.

Nils

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Reduce sinval synchronization overhead.