Re: lazy vxid locks, v1
Greg Stark <stark@mit.edu>
From: Greg Stark <stark@mit.edu>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2011-06-12T21:58:31Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Avoid extra system calls to block SIGPIPE if the platform provides either
- cea80e726edd 9.0.0 cited
On Sun, Jun 12, 2011 at 10:39 PM, Robert Haas <robertmhaas@gmail.com> wrote: > I hacked up the system to > report how often each lwlock spinlock exceeded spins_per_delay. I don't doubt the rest of your analysis but one thing to note, number of spins on a spinlock is not the same as the amount of time spent waiting for it. When there's contention on a spinlock the actual test-and-set instruction ends up taking a long time while cache lines are copied around. In theory you could have processes spending an inordinate amount of time waiting on a spinlock even though they never actually hit spins_per_delay or you could have processes that quickly exceed spins_per_delay. I think in practice the results are the same because the code the spinlocks protect is always short so it's hard to get the second case on a multi-core box without actually having contention anyways. -- greg