| От | Jesper Pedersen |
|---|---|
| Тема | Re: Move PinBuffer and UnpinBuffer to atomics |
| Дата | |
| Msg-id | 5642234F.6070501@redhat.com обсуждение исходный текст |
| Ответ на | Re: Move PinBuffer and UnpinBuffer to atomics (Andres Freund <andres@anarazel.de>) |
| Список | pgsql-hackers |
Hi, On 11/09/2015 05:10 PM, Andres Freund wrote: >> Each graph has a full initdb + pgbench -i cycle now. > > That looks about as we'd expect: the lock-free pinning doesn't matter > and ssynchronous commit is beneficial. I think our bottlenecks in write > workloads are sufficiently elsewhere that it's unlikely that buffer pins > make a lot of difference. > Using https://commitfest.postgresql.org/7/373/ shows that the CLog queue is max'ed out on the number of client connections. > You could try a readonly pgbench workload (i.e. -S), to see whether a > difference is visible there. For a pgbench -S workload it's more likely > that you only see significant contention on larger machines. If you've a > workload that touches more cached buffers, it'd be visible earlier. > Yeah, basically no difference between the 4 -S runs on this setup. >> I know, I have a brown paper bag somewhere. > > Why? This looks as expected, and the issues from the previous run were > easy to make mistakes? > I should have known to do the full cycle of initdb / pgbench -i in the first place. Best regards, Jesper
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера
