Performance with new nested-xacts code
От | Tom Lane |
---|---|
Тема | Performance with new nested-xacts code |
Дата | |
Msg-id | 21989.1088655715@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Performance with new nested-xacts code
Re: Performance with new nested-xacts code Re: Performance with new nested-xacts code |
Список | 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 ispgbench -i -s 10 bench followed by repeatedpgbench -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 по дате отправления: