Re: FSM patch - performance test

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FSM patch - performance test
Date: 2008-09-22 15:41:46
Message-ID: 48D7BCBA.5030908@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-09-22 15:46:23 Re: Initial prefetch performance testing
Previous Message Andrew Dunstan 2008-09-22 15:38:50 Re: parallel pg_restore