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
