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