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
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 |