Re: Concurrent HOT Update interference

From: Greg Stark <stark(at)mit(dot)edu>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Concurrent HOT Update interference
Date: 2013-05-10 12:46:43
Message-ID: CAM-w4HNuhb9RAuz7Q1_aDUnkaf0nvhTvF+2G3uBPj2_OLz9WxA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 10, 2013 at 11:23 AM, Simon Riggs <simon(at)2ndquadrant(dot)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Kirkwood 2013-05-10 12:51:20 Re: In progress INSERT wrecks plans on table
Previous Message Greg Stark 2013-05-10 12:39:10 Re: corrupt pages detected by enabling checksums