Re: unnecessary executor overheads around seqscans

On Tue, Jan 27, 2026 at 3:08 AM Andres Freund <andres(at)anarazel(dot)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