Re: FSM, now without WAL-logging

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, now without WAL-logging
Date: 2008-09-26 13:04:51
Message-ID: 48DCDDF3.5020601@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas napsal(a):
> Zdenek Kotala wrote:

>
> Attached is a new version, now with WAL-logging of the FSM truncation. I
> decided to go with the separate WAL record for that, rather than
> piggybacking on the smgrtruncate's WAL record. It seems much better from
> a modularity point of view this way. I've also worked on the comments,
> renamed many of the internal functions, in a more coherent scheme, and I
> also started using the "struct FSMAddress" you suggested a while ago.
>
> But I don't think I've changed anything that could explain that crash.
> Let me know if it still doesn't work.

This version works on my "old" repo.

I performed performance test (iGEN) on SUN x4600 with 60 concurrent
users and see result:

Original:
---------
MQThL (Maximum Qualified Throughput LIGHT): 1209.60 tpm
MQThM (Maximum Qualified Throughput MEDIUM): 2576.72 tpm
MQThH (Maximum Qualified Throughput HEAVY): 2191.20 tpm

TRANSACTION MIX

Total number of transactions = 181232
TYPE TX. COUNT MIX
---- --------- ---
Light: 30240 16.69%
Medium: 64418 35.54%
DSS: 19865 10.96%
Heavy: 54780 30.23%
Connection: 11929 6.58%

RESPONSE TIMES AVG. MAX. 90TH

Light 0.304 6.405 0.400
Medium 0.317 6.533 0.400
DSS 0.266 6.343 0.020
Heavy 0.361 6.737 3.000
Connections 0.264 5.983 0.400
Number of users = 60
Sum of Avg. RT * TPS for all Tx. Types = 32.770142

FSM with WAL
------------
MQThL (Maximum Qualified Throughput LIGHT): 1199.36 tpm
MQThM (Maximum Qualified Throughput MEDIUM): 2569.12 tpm
MQThH (Maximum Qualified Throughput HEAVY): 2171.64 tpm

TRANSACTION MIX

Total number of transactions = 180625
TYPE TX. COUNT MIX
---- --------- ---
Light: 29984 16.60%
Medium: 64228 35.56%
DSS: 20181 11.17%
Heavy: 54291 30.06%
Connection: 11941 6.61%

RESPONSE TIMES AVG. MAX. 90TH

Light 0.309 6.560 0.400
Medium 0.323 6.529 0.400
DSS 0.268 6.327 0.020
Heavy 0.360 6.675 3.000
Connections 0.274 6.359 0.400
Number of users = 60
Sum of Avg. RT * TPS for all Tx. Types = 32.845712

FSM no WAL last version
-----------------------
MQThL (Maximum Qualified Throughput LIGHT): 1207.92 tpm
MQThM (Maximum Qualified Throughput MEDIUM): 2611.84 tpm
MQThH (Maximum Qualified Throughput HEAVY): 2177.68 tpm

TRANSACTION MIX

Total number of transactions = 182222
TYPE TX. COUNT MIX
---- --------- ---
Light: 30198 16.57%
Medium: 65296 35.83%
DSS: 20118 11.04%
Heavy: 54442 29.88%
Connection: 12168 6.68%

RESPONSE TIMES AVG. MAX. 90TH

Light 0.301 6.106 0.400
Medium 0.315 6.130 0.400
DSS 0.261 5.977 0.020
Heavy 0.361 6.220 3.000
Connections 0.260 6.044 0.400
Number of users = 60
Sum of Avg. RT * TPS for all Tx. Types = 32.696832

-----------------------------------------

I don't see any big difference. Throughput is similar. Only response
time seems to be better with your last FSM version.

I personally happy with performance.

Zdenek

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-09-26 13:19:21 Re: About the parameter of API: PQprepared
Previous Message Russell Smith 2008-09-26 12:56:24 Re: parallel pg_restore - WIP patch