Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size

From: James Coleman <jtc331(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
Date: 2022-06-17 12:33:29
Message-ID: CAAaqYe9CdmTnSY=_diZbH2X0G4_H7k2xm_tL1KKMseQtRNNhmQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 16, 2022 at 10:15 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Fri, 17 Jun 2022 at 11:31, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > hashedscalararrayop/EEOP_HASHED_SCALARARRAYOP is 64 bytes, even though the
> > limit is 40 bytes.
>
> > commit 50e17ad281b8d1c1b410c9833955bc80fbad4078
> > Author: David Rowley <drowley(at)postgresql(dot)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(at)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(at)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-06-17 13:07:21 Re: pg_upgrade (12->14) fails on aggregate
Previous Message Amit Kapila 2022-06-17 08:57:45 Re: Perform streaming logical transactions by background workers and parallel apply