Re: unnecessary executor overheads around seqscans - Mailing list pgsql-hackers

From Amit Langote
Subject Re: unnecessary executor overheads around seqscans
Date
Msg-id CA+HiwqE9g2tb96hgrNH81Q5PeK3YnwT7nrmVCnRWJVjFpKAtEA@mail.gmail.com
Whole thread Raw
In response to Re: unnecessary executor overheads around seqscans  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, Jan 27, 2026 at 3:08 AM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2026-01-26 16:47:31 +0900, Amit Langote wrote:
> > I tried my patch over your committed SeqNext inlining patch and ran
> > the following benchmark but didn't notice in material difference:
> >
> > CREATE TABLE t (a int);
> > INSERT INTO t SELECT generate_series(1, 1000000);
> > ANALYZE t;
>
> Because the table isn't frozen, visibility checks will probably add enough
> per-row overhead to make any per-row micro-optimization harder to see.  On my
> somewhat older workstation freezing is a 17% improvement.
>
> > SET max_parallel_workers_per_gather = 0;
> > SELECT * FROM t WHERE a = -1;
> >
> > Perhaps not too surprising given it's just eliminating a couple of
> > instructions per row that the branch predictor probably handles well
> > anyway? Still seems worth having for code hygiene if nothing else.
> >
> > Same result (no diff in perf) when I apply it over your patch to move
> > the scandesc == NULL check.
>
> FWIW, on my cascade lake workstation it's a, surprisingly large, 3.5%, after
> freezing. Without freezing there maybe still is a difference, but it's very
> close to the noise floor.

I did freeze but still don't see a measurable difference.  Though, I
tested on a VM, so the noise floor is probably higher than on your
bare metal workstation.  I'll try later on bare metal.

--
Thanks, Amit Langote



pgsql-hackers by date:

Previous
From: Tender Wang
Date:
Subject: Re: Optimize IS DISTINCT FROM with non-nullable inputs
Next
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Fix logical decoding not track transaction during SNAPBUILD_BUILDING_SNAPSHOT