Hi,
On 2023-03-13 13:41:19 -0700, Andres Freund wrote:
> On 2023-03-13 21:22:29 +0100, Peter Eisentraut wrote:
> > On 12.03.23 01:11, Andres Freund wrote:
> > > Have you done benchmarks of some simple workloads to verify this doesn't cause
> > > slowdowns (when not using encryption, obviously)? printtup.c is a performance
> > > sensitive portion for simple queries, particularly when they return multiple
> > > columns.
> >
> > The additional code isn't used when column encryption is off, so there
> > shouldn't be any impact.
>
> It adds branches, and it makes tupledescs wider. In tight spots, such as
> printtup, that can hurt, even if the branches aren't ever entered.
In fact, I do see a noticable, but not huge, regression:
$ cat /tmp/test.sql
SELECT * FROM pg_class WHERE oid = 1247;
c=1;taskset -c 10 pgbench -n -M prepared -c$c -j$c -f /tmp/test.sql -P1 -T10
with the server also pinned to core 1, and turbo boost disabled. Nothing else
is allowed to run on the core, or its hyperthread sibling. This is my setup
for comparing performance with the least noise in general, not related to this
patch.
head: 28495.858509 28823.055643 28731.074311
patch: 28298.498851 28285.426532 28489.359569
A ~1.1% loss.
pipelined 50 statements (pgbench pinned to a different otherwise unused core)
head: 1147.404506 1147.587475 1151.976547
patch: 1126.525708 1122.375337 1119.088734
A ~2.2% loss.
That might not be prohibitive, but it does seem worth analyzing.
Greetings,
Andres Freund
