Re: Some ExecSeqScan optimizations

Hi,

On 2025-01-22 10:07:51 +0900, Amit Langote wrote:
> On Fri, Jan 17, 2025 at 2:05 PM Amit Langote <amitlangote09(at)gmail(dot)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(at)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