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
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 |