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-19 14:44:04
Message-ID: 48D3BAB4.4080105@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2008-09-19 15:34:06 Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Previous Message Magnus Hagander 2008-09-19 14:42:07 Re: [HACKERS] 0x1A in control file on Windows