Hi hackers, Bumping this thread as this small patch is passing all CF checks but needs a reviewer.
*The Problem:* Right now, if you write a parallel CustomScan extension, it is impossible to get performance metrics from parallel workers. The data is destroyed during DSM unlinking before the leader can grab it. *The Fix:* This patch adds an optional RetrieveInstrumentation hook to CustomExecMethods. It has zero overhead for existing extensions (it's a simple NULL check) but unlocks metric aggregation for parallel custom scans. Please let me know your thoughts. Thanks, Siddharth On Wed, Apr 8, 2026 at 10:57 AM Siddharth Kothari <[email protected]> wrote: > Hi everyone, > > I’m just checking in to see if anyone has had a chance to look at this or > if there’s any further information I should provide to help with the > review. I have also added the patch to PG20-1 CF queue, the link is > https://commitfest.postgresql.org/patch/6524/. > > Thanks, > Siddharth > > On Wed, Feb 18, 2026 at 3:09 PM Siddharth Kothari <[email protected]> > wrote: > >> Dear PostgreSQL Hackers, >> >> This email proposes a patch to enhance the CustomScan provider interface. >> The patch file, >> 0001-Add-RetrieveInstrumentationCustomScan-hook-for-Custo.patch, is >> attached. >> >> *Problem:* >> >> CustomScan providers currently lack a standard method to aggregate >> instrumentation data from parallel workers back to the leader process >> before the Dynamic Shared Memory (DSM) segment is unlinked. This makes it >> difficult to gather comprehensive performance metrics from parallelized >> custom scans. >> >> *Solution:* >> >> This patch introduces a new optional hook, >> RetrieveInstrumentationCustomScan, to the CustomExecMethods struct. This >> hook allows custom scan providers to implement logic to collect and >> consolidate instrumentation from shared memory or worker states during the >> parallel query cleanup phase. This hook is invoked via the new >> ExecCustomScanRetrieveInstrumentation function, called from >> ExecParallelRetrieveInstrumentation for T_CustomScanState nodes. Since >> the hook is optional (checked for NULL before calling), it maintains full >> backward compatibility. >> >> *Testing & Compatibility:* >> >> - The patch compiles and passes all core regression tests (make >> check-world) on my x86_64 instance. >> - The changes are not platform-specific. >> - Regression Tests: This patch provides a new *capability* for custom >> scan providers. Since the hook's functionality is only realized when >> implemented by an extension, specific tests would naturally reside within >> that extension rather than in the core regression suite. >> >> This patch does not directly address a specific item on the official TODO >> list but enhances the extensibility framework. >> >> I believe this patch is complete and ready for review. I look forward to >> any feedback and am happy to make revisions. I will also add this patch to >> the next CommitFest. >> >> Thank you, >> >> Siddharth Kothari >> >
0001-Add-RetrieveInstrumentationCustomScan-hook-for-Custo.patch
Description: Binary data
