I was all set to launch into a diatribe about the half dozen performance
issues I think we *must* fix in the new nested-transactions code, and
thought I'd back it up by citing some pgbench numbers. So I ran pgbench
runs using yesterday's CVS tip and current. I had to fix a small memory
leak before I could get through pgbench -i at all :-(, but after that I
found that today's tip seems a good 10% faster than yesterday's.
This brought me up short. I sure as heck do not see anything in that
patch that would represent a performance gain over before, especially
not in the very vanilla-flavor cases exercised by pgbench. Do you see
an explanation? I'm a bit worried that we've managed to dike out some
essential operation or other...
Can anyone else reproduce these results? The test case I'm using is
pgbench -i -s 10 bench
followed by repeated
pgbench -c 5 -t 1000 bench
I've built PG with --enable-debug and --enable-cassert, and am running
with -F (fsync off) but otherwise absolutely factory-stock
postgresql.conf. The hardware is a not-so-new-anymore Dell P4 with
run-of-the-mill IDE disk drive, running RHL 8.0. Obviously none of this
is tuned at all, but the question is why did CVS tip get faster when it
should by rights be slower.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
