Re: Spinlock performance improvement proposal

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Spinlock performance improvement proposal
Дата
Msg-id 13231.1001539032@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Spinlock performance improvement proposal  (Neil Padgett <npadgett@redhat.com>)
Список 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 по дате отправления:

Предыдущее
От: Ryan Mahoney
Дата:
Сообщение: Re: casting for dates
Следующее
От: "D. Hageman"
Дата:
Сообщение: Re: Spinlock performance improvement proposal