On Fri, 17 Jun 2022 at 11:31, Andres Freund <andres@anarazel.de> wrote:
> hashedscalararrayop/EEOP_HASHED_SCALARARRAYOP is 64 bytes, even though the
> limit is 40 bytes.
> commit 50e17ad281b8d1c1b410c9833955bc80fbad4078
> Author: David Rowley <drowley@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.
David
