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

From Andres Freund
Subject Re: unnecessary executor overheads around seqscans
Date
Msg-id ia64rgzcqwtmmgimovwiaj7qbzk3s2hvwto2i3obcv7u6sjhue@a5zvxu7y7e57
Whole thread Raw
In response to Re: unnecessary executor overheads around seqscans  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: unnecessary executor overheads around seqscans
List pgsql-hackers
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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Jelte Fennema-Nio
Date:
Subject: Re: meson: Make test output much more useful on failure (both in CI and locally)
Next
From: Robert Haas
Date:
Subject: Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files after relation truncation in segmented tables