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
