Re: Concurrent HOT Update interference

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Concurrent HOT Update interference
Дата
Msg-id CAM-w4HNuhb9RAuz7Q1_aDUnkaf0nvhTvF+2G3uBPj2_OLz9WxA@mail.gmail.com
обсуждение исходный текст
Ответ на Concurrent HOT Update interference  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Fri, May 10, 2013 at 11:23 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> 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.

Without prejudice to the rest of the argument, just a point of history
here. Running pgbench with more clients than the scale factor has been
considered a test of contention and not i/o scaling for a lot longer
than we've had HOT. As far back as I can remember the recommendation
was to run pgbench with fewer sessions than the scale factor. At times
some people (Robert and Greg I think?) have used the reverse
specifically to test contention but that's something programmers are
concerned about, not users.

pgbench isn't great at testing "hot spots" because it uses uniform
random numbers. We've talked about having an option to do a 90/10
distribution to better emulate real usage patterns but I don't think
anyone's done it.

In any case I don't think now is a great time to be bringing up new
ideas like this. Once 9.3 is out the door it'll be a better time for
this kind of out of the box brainstorming.

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: corrupt pages detected by enabling checksums
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Concurrent HOT Update interference