Re: [Testperf-general] Re: 8.0beta5 results w/ dbt2 - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [Testperf-general] Re: 8.0beta5 results w/ dbt2
Date
Msg-id 1101798730.4686.16.camel@localhost.localdomain
Whole thread Raw
In response to Re: 8.0beta5 results w/ dbt2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [Testperf-general] Re: 8.0beta5 results w/ dbt2
List pgsql-hackers
On Tue, 2004-11-30 at 04:35, Tom Lane wrote:
> Mark Wong <markw@osdl.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



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: 8.0beta5 results w/ dbt2
Next
From: Neil Conway
Date:
Subject: Re: [GENERAL] Column n.nsptablespace does not exist error