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