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 по дате отправления: