From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: checkpointer continuous flushing |
Date: | 2015-06-26 19:47:30 |
Message-ID: | alpine.DEB.2.10.1506262125530.32741@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Note that I'm not comparing to HEAD in the above tests, but with the new
> options desactivated, which should be more or less comparable to current
> HEAD, i.e. there is no sorting nor flushing done, but this is not strictly
> speaking HEAD behavior. Probably I should get some figures with HEAD as well
> to check the "more or less" assumption.
Just for answering myself on this point, I tried current HEAD vs patch v4
with sort OFF + flush OFF: the figures are indeed quite comparable (see
below), so although the internal implementation is different, the
performance when both options are off is still a reasonable approximation
of the performance without the patch, as I was expecting. What patch v4
still does with OFF/OFF which is not done by HEAD is balancing writes
among tablespaces, but there is only one disk on these tests so it does
not matter.
tps & stddev full speed:
HEAD OFF/OFF
tiny 1 client 727 +- 227 221 +- 246
small 1 client 158 +- 316 158 +- 325
medium 1 client 148 +- 285 157 +- 326
tiny 4 clients 2088 +- 786 2074 +- 699
small 4 clients 192 +- 648 188 +- 560
medium 4 clients 220 +- 654 220 +- 648
percent of late transactions:
HEAD OFF/OFF
tiny 4 clients 100 tps 6.31 6.67
small 4c 100 tps 35.68 35.23
medium 4c 100 tps 37.38 38.00
tiny 4c 200 tps 9.06 9.10
small 4c 200 tps 51.65 51.16
medium 4c 200 tps 51.35 50.20
tiny 4 clients 400 tps 11.4 10.5
small 4 clients 400 tps 66.4 67.6
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-06-26 19:49:19 | Re: checkpointer continuous flushing |
Previous Message | Jeff Janes | 2015-06-26 19:39:46 | Re: BRIN index bug due to WAL refactoring |