Re: Some ExecSeqScan optimizations

From: Andres Freund <andres(at)anarazel(dot)de>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Junwang Zhao <zhjwpku(at)gmail(dot)com>
Subject: Re: Some ExecSeqScan optimizations
Date: 2025-08-11 20:19:45
Message-ID: h44uho22osw4f5ytet6dr23znwzz3p3jfl54avolptbxnvth7r@j24tuvrmqojg
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2025-07-11 11:22:36 +0900, Amit Langote wrote:
> On Fri, Jul 11, 2025 at 5:55 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2025-07-10 17:28:50 +0900, Amit Langote wrote:
> > > On Thu, Jul 10, 2025 at 8:34 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > > 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.
> > >
> > > Yeah, that seems worthwhile. I had been a bit concerned about code
> > > size growth from having four variant functions with at least some
> > > duplication, so this is a nice offset.
> >
> > I'm rather surprised by just how much the size reduces...
> >
> > I built nodeSeqscan.c with -ffunction-sections and looked at the size with
> > size --format=sysv:
> >
> > Before:
> > .text.SeqRecheck 6 0
> > .rodata.str1.8 135 0
> > .text.unlikely.SeqNext 53 0
> > .text.SeqNext 178 0
> > .text.ExecSeqScanEPQ 20 0
> > .text.ExecSeqScanWithProject 289 0
> > .text.unlikely.ExecSeqScanWithQual 53 0
> > .text.ExecSeqScanWithQual 441 0
> > .text.unlikely.ExecSeqScanWithQualProject 53 0
> > .text.ExecSeqScanWithQualProject 811 0
> > .text.unlikely.ExecSeqScan 53 0
> > .text.ExecSeqScan 245 0
> > .text.ExecInitSeqScan 287 0
> > .text.ExecEndSeqScan 33 0
> > .text.ExecReScanSeqScan 63 0
> > .text.ExecSeqScanEstimate 88 0
> > .text.ExecSeqScanInitializeDSM 114 0
> > .text.ExecSeqScanReInitializeDSM 34 0
> > .text.ExecSeqScanInitializeWorker 64 0
> >
> > After:
> > .text.SeqRecheck 6 0
> > .rodata.str1.8 135 0
> > .text.unlikely.SeqNext 53 0
> > .text.SeqNext 178 0
> > .text.ExecSeqScanEPQ 20 0
> > .text.ExecSeqScanWithProject 209 0
> > .text.unlikely.ExecSeqScanWithQual 53 0
> > .text.ExecSeqScanWithQual 373 0
> > .text.unlikely.ExecSeqScanWithQualProject 53 0
> > .text.ExecSeqScanWithQualProject 474 0
> > .text.unlikely.ExecSeqScan 53 0
> > .text.ExecSeqScan 245 0
> > .text.ExecInitSeqScan 287 0
> > .text.ExecEndSeqScan 33 0
> > .text.ExecReScanSeqScan 63 0
> > .text.ExecSeqScanEstimate 88 0
> > .text.ExecSeqScanInitializeDSM 114 0
> > .text.ExecSeqScanReInitializeDSM 34 0
> > .text.ExecSeqScanInitializeWorker 64 0
> >
> >
> > I'm rather baffled that the size of ExecSeqScanWithQualProject goes from 811
> > to 474, just due to those null checks being removed... But I'll take it.
>
> Wow, indeed.

Thanks for reviewing. Pushed!

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Matheus Alcantara 2025-08-11 20:43:07 Re: SCRAM pass-through authentication for postgres_fdw
Previous Message Paul A Jungwirth 2025-08-11 20:18:03 Re: Foreign key isolation tests