Re: Avoid stack frame setup in performance critical routines using tail calls - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Avoid stack frame setup in performance critical routines using tail calls
Date
Msg-id 20230719085236.jltxal2eztqrprfg@awork3.anarazel.de
Whole thread Raw
In response to Avoid stack frame setup in performance critical routines using tail calls  (Andres Freund <andres@anarazel.de>)
Responses Re: Avoid stack frame setup in performance critical routines using tail calls
Re: Avoid stack frame setup in performance critical routines using tail calls
List pgsql-hackers
Hi,

David and I were chatting about this patch, in the context of his bump
allocator patch.  Attached is a rebased version that is also split up into two
steps, and a bit more polished.

I wasn't sure what a good test was. I ended up measuring
  COPY pgbench_accounts TO '/dev/null' WITH (FORMAT 'binary');
of a scale 1 database with pgbench:

c=1;pgbench -q -i -s1 && pgbench  -n -c$c -j$c -t100 -f <(echo "COPY pgbench_accounts TO '/dev/null' WITH (FORMAT
'binary');")

    average latency
HEAD:   33.865 ms
01:     32.820 ms
02:     29.934 ms

The server was pinned to the one core, turbo mode disabled.  That's a pretty
nice win, I'd say.  And I don't think this is actually the most allocator
bound workload, I just tried something fairly random...


Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: unrecognized node type while displaying a Path due to dangling pointer
Next
From: Tomas Vondra
Date:
Subject: Re: Use of additional index columns in rows filtering