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

Performance with new nested-xacts code

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Performance with new nested-xacts code
Date: 2004-07-01 04:21:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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


pgsql-hackers by date

Next:From: Joe ConwayDate: 2004-07-01 04:24:31
Subject: compile warnings
Previous:From: Justin CliftDate: 2004-07-01 03:00:15
Subject: Adding column comment to information_schema.columns

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