Re: FSM, now without WAL-logging

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FSM, now without WAL-logging
Date: 2008-09-26 13:20:21
Message-ID: 48DCE195.7000506@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zdenek Kotala wrote:
> I performed performance test (iGEN) on SUN x4600 with 60 concurrent
> users and see result:
>
> ...
>
> 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.

Thanks! I've been running DBT-2 tests myself, and I'm not seeing any
difference there either:

testno TPM NO90 time comment
36 1405 1.724 6h fsm-nowal
35 1421 0.761 6h CVS HEAD
34 1439 1.066 2h fsm-nowal
33 1442 0.868 2h CVS HEAD

The NO90 is the 90% percentile of New Order transaction response time.
there's big variation there in the 6h tests, because of a huge dip in
performance near the end of the test, both with and without the patch. I
don't have an explanation for the dips, but it throws off the response
times for the whole tests. Given that in the 2h tests, which is exactly
the same as the 6h test, just shorter, there's no degradation in the
response times, I'm not worried about that.

I don't have access to the site where I used to publish the test results
earlier, but let me know if you want to see the full test results, and
I'll try to zip them up and FTP somewhere (~500 MB uncompressed).

I've also tried various pgbench tests, on a RAM disk and otherwise, as
well as the "table population" test I ran earlier, and don't see any
difference in performance.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2008-09-26 13:25:04 Re: parallel pg_restore - WIP patch
Previous Message Tom Lane 2008-09-26 13:19:21 Re: About the parameter of API: PQprepared