Re: Spinlock performance improvement proposal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Spinlock performance improvement proposal
Date
Msg-id 13231.1001539032@sss.pgh.pa.us
Whole thread Raw
In response to Re: Spinlock performance improvement proposal  (Neil Padgett <npadgett@redhat.com>)
List pgsql-hackers
Neil Padgett <npadgett@redhat.com> writes:
> Well. Currently the runs are the typical pg_bench runs.

With what parameters?  If you don't initialize the pg_bench database
with "scale" proportional to the number of clients you intend to use,
then you'll naturally get huge lock contention.  For example, if you
use scale=1, there's only one "branch" in the database.  Since every
transaction wants to update the branch's balance, every transaction
has to write-lock that single row, and so everybody serializes on that
one lock.  Under these conditions it's not surprising to see lots of
lock waits and lots of useless runs of the deadlock detector ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Ryan Mahoney
Date:
Subject: Re: casting for dates
Next
From: "D. Hageman"
Date:
Subject: Re: Spinlock performance improvement proposal