| От | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера