Re: Concurrent HOT Update interference
От | Tom Lane |
---|---|
Тема | Re: Concurrent HOT Update interference |
Дата | |
Msg-id | 3488.1368191636@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Concurrent HOT Update interference (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Concurrent HOT Update interference
|
Список | pgsql-hackers |
Simon Riggs <simon@2ndQuadrant.com> writes: > So what we have is that multiple UPDATEs repeatedly accessing the same > block will prevent each other from successful cleanup, since while one > session is performing the update, the second session is pinning the > block with an indexscan. > This effect has been noted for some time during pgbench runs, where > running with more sessions than scale factors causes contention. We've > never done anything about it because that's been seen as a poorly > executed test, whereas it does actually match the real situation we > experience at "hot spots" in the table. Uh, no. pgbench's problem at high scale factors is that multiple sessions want to update *the same row*, not just different rows on the same page. That contention is unavoidable. You may in fact have a good point, but you can't prove it by reference to pgbench. regards, tom lane
В списке pgsql-hackers по дате отправления: