On Fri, Jun 15, 2012 at 9:43 AM, Merlin Moncure <mmonc...@gmail.com> wrote: > On Thu, Jun 14, 2012 at 4:39 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Jan 11, 2012 at 8:48 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> I've had cause, a few times this development cycle, to want to measure >>> the amount of spinning on each lwlock in the system. To that end, >>> I've found the attached patch useful. Note that if you don't define >>> LWLOCK_STATS, this changes nothing except that the return value from >>> s_lock becomes int rather than void. If you do define LWLOCK_STATS, >>> then LWLockAcquire() counts the number of pg_usleep() calls that are >>> required to acquire each LWLock, in addition to the other statistics. >>> Since this has come up for me a few times now, I'd like to proposing >>> including it in core. >> >> Well, this fell through the cracks, because I forgot to add it to the >> January CommitFest. Here it is again, rebased. > > +1. It might be too awkward to add, but it would be nice to be able > to fetch the number of spins as well as number of delays (aside, it's > a bit confusing that in s_lock.c 'delay' is used both for the hardware > sleep as well as the yielding sleep).
Yeah, I'm inclined to keep it simple for now. We can always change it again later if someone comes up with something better. I suspect that delays probably tracks "contention bad enough that you should be worried" pretty well, but of course I might be wrong. The only thing I know for sure is that I've found this useful in my own testing, and therefore others testing with LWLOCK_STATS might also find it useful. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
