Re: why roll-your-own s_lock? / improving scalability
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nils Goroll <slink@schokola.de>
Cc: pgsql-hackers@postgresql.org
Date: 2012-06-26T18:50:51Z
Lists: pgsql-hackers
Nils Goroll <slink@schokola.de> writes: > Now that the scene is set, here's the simple question: Why all this? Why not > simply use posix mutexes which, on modern platforms, will map to efficient > implementations like adaptive mutexes or futexes? (1) They do not exist everywhere. (2) There is absolutely no evidence to suggest that they'd make things better. If someone cared to rectify (2), we could consider how to use them as an alternative implementation. But if you start with "let's not support any platforms that don't have this feature", you're going to get a cold reception. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Reduce sinval synchronization overhead.
- b4fbe392f8ff 9.2.0 cited