Skip site navigation (1) Skip section navigation (2)

Re: [Testperf-general] Re: 8.0beta5 results w/ dbt2

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark Wong <markw(at)osdl(dot)org>, testperf-general(at)pgfoundry(dot)org,pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Testperf-general] Re: 8.0beta5 results w/ dbt2
Date: 2004-11-30 07:12:10
Message-ID: 1101798730.4686.16.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 2004-11-30 at 04:35, Tom Lane wrote:
> Mark Wong <markw(at)osdl(dot)org> writes:
> > I have some initial results using 8.0beta5 with our OLTP workload.
> > Off the bat I see about a 23% improvement in overall throughput.
> Between beta4 and beta5?  That's astonishing.  We didn't really do very
> much that was performance-focused.  Digging in the CVS logs, I see only
> some changes intended to speed up subtransaction commit, which I suppose
> is not relevant to your benchmark, plus these two changes:
> 2004-11-16 22:13  neilc
> 	* src/backend/access/: hash/hash.c, nbtree/nbtree.c:
> 	Micro-optimization of markpos() and restrpos() in btree and hash
> 	indexes.  Rather than using ReadBuffer() to increment the reference
> 	count on an already-pinned buffer, we should use
> 	IncrBufferRefCount() as it is faster and does not require acquiring
> 	the BufMgrLock.
> 2004-11-09 16:42  tgl
> 	* src/backend/optimizer/util/clauses.c: Allow planner to fold
> 	"stable" functions to constants when forming selectivity estimates,
> 	per recent discussion.
> Given the right sort of queries I suppose the second change might create
> a significant improvement, but I wasn't expecting 23% on a
> general-purpose benchmark...

Hmm... well it is a GP benchmark, but the results are based upon the
performance of one transaction while in the presence of the other
workloads. Speed up New Order and the whole thing improves. 

If you look at the graph of New Order response time distribution, the
higher result gives much more frequent sub-second response for 8.0beta5
and the hump at around 23secs has moved down to 14secs. Notably, the
payment transaction and stock level transaction have almost identical
response time peaks in both cases. Perhaps some interaction between them
has been slowing us down? Now its gone...

The results seem to be significantly different, so I believe the
results. Well done Mark - great new graphs. Any chance we could see the
graphs showing 0.5 sec bins on the x axis, with all data < 0.5 sec
removed from the graph so we can show the tail? Or point me at the data?

Very pleased....

This shows me one additional thing: we aren't using sufficiently good
instrumentation to understand where the problems lie.

Best Regards, Simon Riggs

In response to


pgsql-hackers by date

Next:From: Neil ConwayDate: 2004-11-30 07:29:45
Subject: Re: Column n.nsptablespace does not exist error
Previous:From: Greg StarkDate: 2004-11-30 07:00:29
Subject: Re: 8.0beta5 results w/ dbt2

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group