MIME-Version: 1.0
References: <20210719195950.gavgs6ujzmjfaiig@alap3.anarazel.de>
In-Reply-To: <20210719195950.gavgs6ujzmjfaiig@alap3.anarazel.de>
From: David Rowley <dgrowleyml@gmail.com>
Date: Tue, 20 Jul 2021 16:50:09 +1200
Message-ID: 
 <CAApHDvpQQc67NbYJkM0GZWVw_wZvUvOuuANCPiOyobV=q1=owA@mail.gmail.com>
Subject: Re: Avoid stack frame setup in performance critical routines using
 tail calls
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Robert Haas <robertmhaas@gmail.com>,
	Michael Paquier <michael.paquier@gmail.com>, Tomas Vondra <tv@fuzzy.cz>
Content-Type: multipart/mixed; boundary="0000000000002b82c005c786cb7b"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvpQQc67NbYJkM0GZWVw_wZvUvOuuANCPiOyobV%3Dq1%3DowA%40mail.gmail.com>
Precedence: bulk

--0000000000002b82c005c786cb7b
Content-Type: text/plain; charset="UTF-8"

On Tue, 20 Jul 2021 at 08:00, Andres Freund <andres@anarazel.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

--0000000000002b82c005c786cb7b
Content-Type: text/plain; charset="US-ASCII"; name="benchresults.txt"
Content-Disposition: attachment; filename="benchresults.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_krbksdy90>
X-Attachment-Id: f_krbksdy90

CW1hc3RlcglkZW5zZSBoYXNoIExvY2tSZWxlYXNlQWxsICsgYXNldCB0YWlsIGNhbGwJYXNldCB0
YWlsIGNhbGwJZGVuc2UgaGFzaCBMb2NrUmVsZWFzZUFsbAoxMAkzNzU4MjAxLjIJMzc0MTkyNS42
CTM3Mzc3MDEuNQkzNzEzNTIxLjUKMjAJMzgxMDEyNS41CTM4NjE1NzIuNQkzODMwODYzLjcJMzg0
NDE0Mi45CjMwCTM4MDY1MDUuMQkzODUxMTY0LjQJMzgzMjI1Ny45CTM4NDg0NTgKNDAJMzgxNjA5
NC44CTM4NTUyMzIuNAkzODMyMzA1LjcJMzg1NTcwNi42CjUwCTM4MjAzMTcuMgkzODQ2OTQxCTM4
Mjk2NDEuNQkzODUxNzE3LjcKNjAJMzgyNzgwOQkzODQ5NDkwLjQJMzgxMjI1NC41CTM4NTE0OTku
NAo3MAkzODI4NzU3LjkJMzg0NDU4Mi44CTM4MjkwOTcuOAkzODQ5MzEyCjgwCTM4MjQ0OTIuMQkz
ODQzMTYxLjgJMzgyMTM4MwkzODUyMzc4LjgKOTAJMzgxNjUwMi4xCTM4NTE5NzAuOAkzODI1MTE5
LjIJMzg1NDc5My44CjEwMAkzODE5MTI0LjEJMzgzOTY5NS41CTM4MzkyODYuNwkzODYwNDE4LjYK
MTEwCTM4MTYxNTQuMwkzODUxMzAyLjgJMzgyMTIwOS41CTM4NDUzMjcuNwoxMjAJMzgxNzA3MC41
CTM4NTI5NzQuMgkzODMzNzgxCTM4NDU4NDIuNQoxMzAJMzgxNTQyNC43CTM4NTQzNzkuMQkzODMw
ODEyLjUJMzg0NzYyNgoxNDAJMzgyMzYzMS4xCTM4NTI0NDkuMQkzODI1MjYxLjkJMzg0Njc2MC42
CjE1MAkzODIwOTYzLjgJMzgzNzQ5My41CTM4MjA3MDMuMgkzODQwMTk2LjYKMTYwCTM4Mjc3MzcJ
MzgzNzgwOS43CTM4MzUyNzguNAkzODQxMTQ5LjMKMTcwCTM4Mjc3NzkuMgkzODUxNzk5LjQJMzgx
ODQzMC4zCTM4NDAxMzAuOQoxODAJMzgyOTM1MgkzODUzMDk0CTM4MjMyODYuMQkzODQyODE0LjUK
MTkwCTM4MjU1MTguMwkzODU0OTEyLjgJMzgxNjMyOS40CTM4NDE5OTEKMjAwCTM4MjM0NzcuMgkz
ODM4OTk4LjYJMzgxNjA2MC44CTM4MzkzOTAuNwoyMTAJMzgwOTMwNC4zCTM4NDU3NzYuNwkzODE0
NzM3LjIJMzgzNjQzMy41CjIyMAkzODE0MzI4LjUJMzg0MTM5NC43CTM4MTg4OTQJMzg0MjA3My43
CjIzMAkzODExMzk5LjMJMzgzOTM2MC44CTM4MTE5MzkJMzg0Mzc4MC43CmF2ZwkzODE2OTU5LjUz
CTM4NDMzNjguODA5CTM4MjA3MjMuMjUyCTM4NDA2NzIuNDc4CgkJMTAwLjY5JQkxMDAuMTAlCTEw
MC42MiU=
--0000000000002b82c005c786cb7b--