Re: basic pgbench runs with various performance-related patches

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: basic pgbench runs with various performance-related patches
Date: 2012-02-04 16:59:42
Message-ID: 4F2D63FE.30200@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/24/2012 08:58 AM, Robert Haas wrote:
> One somewhat odd thing about these numbers is that, on permanent
> tables, all of the patches seemed to show regressions vs. master in
> single-client throughput. That's a slightly difficult result to
> believe, though, so it's probably a testing artifact of some kind.

It looks like you may have run the ones against master first, then the
ones applying various patches. The one test artifact I have to be very
careful to avoid in that situation is that later files on the physical
disk are slower than earlier ones. There's a >30% differences between
the fastest part of a regular hard drive, the logical beginning, and its
end. Multiple test runs tend to creep forward onto later sections of
disk, and be biased toward the earlier run in that case. To eliminate
that bias when it gets bad, I normally either a) run each test 3 times,
interleaved, or b) rebuild the filesystem in between each initdb.

I'm not sure that's the problem you're running into, but it's the only
one I've been hit by that matches the suspicious part of your results.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2012-02-04 17:14:45 Re: [v9.2] Add GUC sepgsql.client_label
Previous Message Simon Riggs 2012-02-04 16:11:43 Re: BUG #6425: Bus error in slot_deform_tuple