On Thu, Jun 16, 2022 at 10:15 PM David Rowley <dgrowle...@gmail.com> wrote: > > On Fri, 17 Jun 2022 at 11:31, Andres Freund <and...@anarazel.de> wrote: > > hashedscalararrayop/EEOP_HASHED_SCALARARRAYOP is 64 bytes, even though the > > limit is 40 bytes. > > > commit 50e17ad281b8d1c1b410c9833955bc80fbad4078 > > Author: David Rowley <drow...@postgresql.org> > > Date: 2021-04-08 23:51:22 +1200 > > > > Speedup ScalarArrayOpExpr evaluation > > I've put together the attached patch which removes 4 fields from the > hashedscalararrayop portion of the struct which, once the JSON part is > fixed, will put sizeof(ExprEvalStep) back down to 64 bytes again. > > The attached patch causes some extra pointer dereferencing to perform > a hashed saop step, so I tested the performance on f4fb45d15 (prior to > the JSON patch that pushed the sizeof(ExprEvalStep) up further. I > found: > > setup: > create table a (a int); > insert into a select x from generate_series(1000000,2000000) x; > > bench.sql > select * from a where a in(1,2,3,4,5,6,7,8,9,10); > > f4fb45d15 + reduce_sizeof_hashedsaop_ExprEvalStep.patch > drowley@amd3990x:~$ pgbench -n -f bench.sql -T 60 -M prepared postgres > tps = 44.841851 (without initial connection time) > tps = 44.986472 (without initial connection time) > tps = 44.944315 (without initial connection time) > > f4fb45d15 > drowley@amd3990x:~$ pgbench -n -f bench.sql -T 60 -M prepared postgres > tps = 44.446127 (without initial connection time) > tps = 44.614134 (without initial connection time) > tps = 44.895011 (without initial connection time) > > (Patched is ~0.61% faster here) > > So, there appears to be no performance regression due to the extra > indirection. There's maybe even some gains due to the smaller step > size.
I didn't see that comment when working on this (it's quite a long unioned struct; I concur on adding an assert to catch it). This patch looks very reasonable to me though. James Coleman
