From: Gregory Stark <stark@enterprisedb.com>
To: Josh Berkus <josh@agliodbs.com>
Cc: Euler Taveira de Oliveira <euler@timbira.com>
Cc: Greg Smith <gsmith@gregsmith.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: [pgsql-advocacy] Benchmarks WAS: Sun Talks about MySQL
Date: Mon, 28 Apr 2008 05:17:08 -0400
Message-ID: <877iei9w4r.fsf@oxford.xeocode.com> (raw)
In-Reply-To: <4814BDB8.2030108@agliodbs.com>
References: <480F8C2D.6010806@emproshunts.com>
<4811D1DD.9030401@otg-nc.com>
<20080425130105.GA19447@crankycanuck.ca>
<36e682920804250741p33d621f3gf35e6bdebe2e0531@mail.gmail.com>
<20080425152053.GE19447@crankycanuck.ca>
<Pine.GSO.4.64.0804251942060.28069@westnet.com>
<481278E7.9030504@timbira.com>
<87wsmlm90e.fsf@oxford.xeocode.com>
<4814BDB8.2030108@agliodbs.com>
"Josh Berkus" <josh@agliodbs.com> writes:
>> I think TPC-E will make both of these major improvements much more important.
>> I suspect it would be hard to get 8.2 to even pass TPC-E due to the checkpoint
>> dropouts.
>
> You'd be surprised, then. We're still horribly, horribly lock-bound on TPC-E;
> on anything over 4 cores lock resolution chokes us to death. See Jignesh's and
> Paul's various posts about attempts to fix this.
Most of those posts have been about scalability issues with extremely large
numbers of sessions. Those are interesting too and they may be limiting our
results in benchmarks which depend on such a configuration (which I don't
think includes TPC-E, but the benchmark Jignesh has been writing about is some
Java application benchmark which may be such a beast) but they don't directly
relate to whether we're "passing" TPC-E.
What I was referring to by "passing" TPC-E was the criteria for a conformant
benchmark run. TPC-C has iirc, only two relevant criteria: "95th percentile
response time < 5s" and "average response time < 95th percentile response
time". You can pass those even if 1 transaction in 20 takes 10-20s which is
more than enough to cover checkpoints and other random sources of inconsistent
performance.
TPC-E has more stringent requirements which explicitly require very consistent
response times and I doubt 8.2 would have been able to pass them. So the
performance limiting factors whether they be i/o, cpu, lock contention, or
whatever don't even come into play. We wouldn't have any conformant results
whatsoever, not even low values limited by contention. 8.3 however should be
in a better position to pass.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: stark@enterprisedb.com, josh@agliodbs.com, euler@timbira.com, gsmith@gregsmith.com
Subject: Re: [pgsql-advocacy] Benchmarks WAS: Sun Talks about MySQL
In-Reply-To: <877iei9w4r.fsf@oxford.xeocode.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox