On Nov 21, 2007 7:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > FWIW, the test cases I was just comparing are entirely CPU-bound --- > vmstat says there are no disk reads happening at all. Now I only got a > 3% drop, so that may not be the same effect Guillaume is seeing. But > the whole thing is a bit upsetting seeing that we thought we'd reduced > the overhead for short read-only transactions ...
A month or so ago I mentioned to Bruce that we were seeing this behavior (accidentally) but hadn't had time to focus on it or determine whether it was a tuning issue. Basically we're performing the same select-only pgbench test, but with a varying scale from 1 to 1000. In almost all cases, 8.2.5 is faster than 8.3 by about 2-5 percent. The script given to us by a customer was as follows: for scale in 1 2 5 10 20 30 40 50 75 100 200 400 800 1000; do echo "------------------------------------------------------------" echo "SCALE $scale" dropdb pgbench createdb pgbench pgbench -p 5432 -i -s $scale pgbench psql pgbench -c 'CHECKPOINT' pgbench -p 5432 -c 8 -t 2500 -S pgbench pgbench -p 5432 -c 8 -t 2500 -S pgbench pgbench -p 5432 -c 8 -t 2500 -S pgbench done -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 499 Thornall Street, 2nd Floor | [EMAIL PROTECTED] Edison, NJ 08837 | http://www.enterprisedb.com/ ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend