Re: Concurrent HOT Update interference - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Concurrent HOT Update interference
Date
Msg-id CAM-w4HNuhb9RAuz7Q1_aDUnkaf0nvhTvF+2G3uBPj2_OLz9WxA@mail.gmail.com
Whole thread Raw
In response to Concurrent HOT Update interference  (Simon Riggs <simon@2ndQuadrant.com>)
List 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 by date:

Previous
From: Greg Stark
Date:
Subject: Re: corrupt pages detected by enabling checksums
Next
From: Tom Lane
Date:
Subject: Re: Concurrent HOT Update interference