Horton

Re: Some ExecSeqScan optimizations

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Amit Langote <amitlangote09@gmail.com>
Cc: David Rowley <dgrowleyml@gmail.com>, Vladlen Popolitov <v.popolitov@postgrespro.ru>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Junwang Zhao <zhjwpku@gmail.com>
Date: 2025-07-09T23:34:21Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Refactor ExecScan() to allow inlining of its core logic

Attachments

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