Re: FSM patch - performance test - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: FSM patch - performance test
Date
Msg-id 48D3BAB4.4080105@sun.com
Whole thread Raw
In response to Re: FSM patch - performance test  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: FSM patch - performance test  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
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...

Second idea is that new FSM creates heavy defragmented data and index scan needs 
to jump from one page to another too often.
    Thoughts?
        Zdenek

PS: I'm leaving now and I will be online on Monday.


-- 
Zdenek Kotala              Sun Microsystems
Prague, Czech Republic     http://sun.com/postgresql



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [BUGS] 0x1A in control file on Windows
Next
From: "Robert Haas"
Date:
Subject: Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)