| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz> |
| Subject: | Re: Avoid stack frame setup in performance critical routines using tail calls |
| Date: | 2021-07-20 04:50:09 |
| Message-ID: | CAApHDvpQQc67NbYJkM0GZWVw_wZvUvOuuANCPiOyobV=q1=owA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 20 Jul 2021 at 08:00, Andres Freund <andres(at)anarazel(dot)de> wrote:
> I have *not* carefully benchmarked this, but a quick implementation of this
> does seem to increase readonly pgbench tps at a small scale by 2-3% (both
Interesting.
I've not taken the time to study the patch but I was running some
other benchmarks today on a small scale pgbench readonly test and I
took this patch for a spin to see if I could see the same performance
gains.
This is an AMD 3990x machine that seems to get the most throughput
from pgbench with 132 processes
I did: pgbench -T 240 -P 10 -c 132 -j 132 -S -M prepared
--random-seed=12345 postgres
master = dd498998a
Master: 3816959.53 tps
Patched: 3820723.252 tps
I didn't quite get the same 2-3% as you did, but it did come out
faster than on master.
David
| Attachment | Content-Type | Size |
|---|---|---|
| benchresults.txt | text/plain | 1.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2021-07-20 05:01:43 | Re: O_DIRECT on macOS |
| Previous Message | Michael Paquier | 2021-07-20 04:31:30 | Re: Introduce pg_receivewal gzip compression tests |