Re: Some ExecSeqScan optimizations
Andres Freund <andres@anarazel.de>
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-08-11T20:19:45Z
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 →
-
Refactor ExecScan() to allow inlining of its core logic
- fb9f955025f7 18.0 landed
Hi, On 2025-07-11 11:22:36 +0900, Amit Langote wrote: > On Fri, Jul 11, 2025 at 5:55 AM Andres Freund <andres@anarazel.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@anarazel.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@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