On Tue, 2004-11-30 at 04:35, Tom Lane wrote: > Mark Wong <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
