Re: Spinlock performance improvement proposal

Neil Padgett <npadgett@redhat.com> writes:
> Initial results (top five -- if you would like a complete profile, let
> me know):
> Each sample counts as 1 samples.
>   %   cumulative   self              self     total           
>  time   samples   samples    calls  T1/call  T1/call  name    
>  26.57  42255.02 42255.02                             FindLockCycleRecurse

Yipes.  It would be interesting to know more about the locking pattern
of your benchmark --- are there long waits-for chains, or not?  The
present deadlock detector was certainly written with an eye to "get it
right" rather than "make it fast", but I wonder whether this shows a
performance problem in the detector, or just too many executions because
you're waiting too long to get locks.

> However, this seems to be a red herring. Removing the deadlock detector
> had no effect. In fact, benchmarking showed removing it yielded no
> improvement in transaction processing rate on uniprocessor or SMP
> systems. Instead, it seems that the deadlock detector simply amounts to
> "something to do" for the blocked backend while it waits for lock
> acquisition. 

Do you have any idea about the typical lock-acquisition delay in this
benchmark?  Our docs advise trying to set DEADLOCK_TIMEOUT higher than
the typical acquisition delay, so that the deadlock detector does not
run unnecessarily.

> For example, there has been some suggestion
> that perhaps some component of the database is causing large lock
> contention.

My thought as well.  I would certainly recommend that you use more than
one test case while looking at these things.

			regards, tom lane