Re: 7.2 is slow? - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: 7.2 is slow?
Date
Msg-id 3C1E0CBA.BE8948EF@tm.ee
Whole thread Raw
In response to 7.2 is slow?  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: 7.2 is slow?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
It seems that on dual PIII we are indeed faster than 7.1.3 for 
small number of clients but slower for large number (~ 40)

My initial results on dual PIII/800 are as follows
                                     7.1.3      7.2b4  7.2b4-FULL
==================================================================
./pgbench -i -p 5433 
./pgbench -p 5433 -c  1 -t 100       240/251    217/223    177/181
./pgbench -p 5433 -c  5 -t 100        93/ 94    211/217    207/212
./pgbench -p 5433 -c 10 -t 100        57/ 58    145/148    160/163
------------------------------------------------------------------
./pgbench -i -s 10 -p 5433 
./pgbench -p 5433 -c   1 -t 100      171/177    162/166    169/173
./pgbench -p 5433 -c   5 -t 100      140/143    191/196    202/207
./pgbench -p 5433 -c  10 -t 100      132/135    165/168    159/163
./pgbench -p 5433 -c  25 -t 100       65/ 66     60/ 60     75/ 76
./pgbench -p 5433 -c  50 -t 100       60/ 61     43/ 43     55/ 59
./pgbench -p 5433 -c 100 -t 100       48/ 48     23/ 23     34/ 34
------------------------------------------------------------------

One of thereasons seems to be that vacuum has chaged

after oding 

psql -p 5433 -c 'vacuum full'

the result of

./pgbench -p 5433 -c 100 -t 100

was 34/34 - still ~25% slower than 7.1.3 but much better 
than with non-full vacuum (which I guess is used by pgbench

The third column 7.2b4-FULL is done by running  "psql -p 5433 -c 'vacuum full'"
between each pgbench run - now the lines cross somwhere 
between 25 and 50 concurrent users

One of the reasons pg is slower on last limes of my test is that 
postgres is slower when vacuum is not done often enough - 
on fresh db
"./pgbench -p 5433 -c 100 -t 10"  gives   67/75 as result
indicating that one reason is just our non-overwriting storage manager.


I also tried to outsmart pg by running the new vacuum 
concurrently, but was disappointed.

vacuuming in 'normal' psql gave me 20/20 tps and running 
with nice psql gave 21/21 tps
running ./pgbench -p 5433 -c 100 -t 100 as first benchmark gave the 
same result as running it after vacuum full


-----------------------------------------------------------------------
PS. I hope to get single-processor results from the same computer in 
about 6 hours as well (after my co-worker arrives home and can reboot 
his computer to single-user)

Inxc - after you have rebooted to single-processor mode, pleas start 
the postgres daemon by

su - hannu
cd db/7.2b4/
bin/pg_ctl -D data -l logfile

and ther run above pgbench commands from 
cd /home/hannu/src/postgresql-7.1.3/contrib/pgbench/
-----------------------------------------------------------------------


pgsql-hackers by date:

Previous
From: Brent Verner
Date:
Subject: Re: [PATCHES] system catalog relation of a table and a serial sequence
Next
From: Hannu Krosing
Date:
Subject: Re: 7.2 is slow?