Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Zdenek Kotala napsal(a):
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Can you do some analysis of why that is?
I tested it several times and last test was surprise for me. I run
original server (with old FSM) on the database which has been created
by new server (with new FSM) and performance is similar (maybe new
implementation is little bit better):
MQThL (Maximum Qualified Throughput LIGHT): 1348.90 tpm
MQThM (Maximum Qualified Throughput MEDIUM): 2874.76 tpm
MQThH (Maximum Qualified Throughput HEAVY): 2422.20 tpm
The question is why? There could be two reasons for that. One is
realated to OS/FS or HW. Filesystem could be defragmented or HDD is
slower in some part...
Ugh. Could it be autovacuum kicking in at different times? Do you get
any other metrics than the TPM out of it.
I don't think that it is autovacuum problem. I run test more times and result
was same. But today I created fresh database and I got similar throughput for
original and new FSM implementation. It seems to me that I hit a HW/OS
singularity. I'll verify it tomorrow.
I recognize only little bit slowdown during index creation, (4:11mins vs.
3:47mins), but I tested it only once.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
