Re: Some ExecSeqScan optimizations - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Some ExecSeqScan optimizations
Date
Msg-id tqlmkwh654vwa37wv3lnefji3tm46iiub7hxkecwh6rimnrh2h@k64nn4lm4tl7
Whole thread Raw
Responses Re: Some ExecSeqScan optimizations
List pgsql-hackers
Hi,

On 2025-01-22 10:07:51 +0900, Amit Langote wrote:
> On Fri, Jan 17, 2025 at 2:05 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > Here's v5 with a few commit message tweaks.
> >
> > Barring objections, I would like to push this early next week.
> 
> Pushed yesterday.  Thank you all.

While looking at a profile I recently noticed that ExecSeqScanWithQual() had a
runtime branch to test whether qual is NULL, which seemed a bit silly. I think
we should use pg_assume(), which I just added to avoid a compiler warning, to
improve the code generation here.

The performance gain unsurprisingly isn't significant (but seems repeatably
measureable), but it does cut out a fair bit of unnecessary code.

andres@awork3:/srv/dev/build/postgres/m-dev-optimize$ size executor_nodeSeqscan.c.*o
   text       data        bss        dec        hex    filename
   3330          0          0       3330        d02    executor_nodeSeqscan.c.assume.o
   3834          0          0       3834        efa    executor_nodeSeqscan.c.o

A 13% reduction in actual code size isn't bad for such a small change, imo.



I have a separate question as well - do we need to call ResetExprContext() if
we neither qual, projection nor epq?  I see a small gain by avoiding that.

Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: gcc 15 "array subscript 0" warning at level -O3
Next
From: Thomas Munro
Date:
Subject: Re: Remaining dependency on setlocale()