Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1whXCc-000HiR-2L for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jul 2026 18:40:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1whXCZ-008sTS-25 for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jul 2026 18:40:56 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1whXCZ-008sTA-00 for pgsql-hackers@lists.postgresql.org; Wed, 08 Jul 2026 18:40:56 +0000 Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1whXCW-00000000CMj-41oB for pgsql-hackers@lists.postgresql.org; Wed, 08 Jul 2026 18:40:54 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 2FCA23F6F9; Wed, 8 Jul 2026 18:40:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vondra.me; s=gm1; t=1783536050; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hODzMICb4Y4degy9Qiu7yJRwzyhoygQSJ8g+Cqjdso8=; b=G69XFNAFLiZk60q+TIyJl4ddBONyOk0Qd/ZOaTII3Jw8+IkvnR4dM3JFOSR4wBbHgoPUyH leohcBy6hRgMP1IULQVASgQdzUDKpJnzyaToSPVkhw/lIF0wBPy2QY+YupU+H/sxnVaytw NtSx2AwaDWaebIKeXVEQRuhNTbGl6gVmhvFstEWGLoiearLKaRA/pl29hSSjufNxYdNJW7 xbkNHshSmwgW46qS9ONXz3qKcImQz/ehLWPsFzIi/ddSjqF57wcXddaZb02f7lxogKoHoF RcZfzGpwlZqcfXGHAHrdZkx+OZjKKyaxNiBeHbJcxekfgN3DExPN/AvhBa1pzA== Message-ID: <861a5330-01ef-446e-ab7f-d34bcd188709@vondra.me> Date: Wed, 8 Jul 2026 20:40:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Add RetrieveInstrumentation hook for CustomScan providers To: Siddharth Kothari , pgsql-hackers@lists.postgresql.org Cc: Vaibhav Jain , Madhukar , Melanie Plageman References: Content-Language: en-US From: Tomas Vondra In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-GND-Sasl: tomas@vondra.me X-GND-State: clean X-GND-Score: -100 X-GND-Cause: dmFkZTFbYSxcyZ/sXDsEetc4XyMnvsRKZu7uO5WFMcTb/4L5nwkxw+koR8zCBNklZisowGXPgyBPeheCdb8Xx9Te60qKLU9sZxAyA12MkNDQswNiPh2kc+DHsKWTWoQuyZtjHosvTMeDspjVBh1eRUuueK7Hogp+J9rOkgsLI+jGQr2pl9FKR7dQWZYLI/VsAfGIGPy4Hwa0S8TN1j9wjKifECZxGYHMzMa0ZljT+8xxmpu8o4JJsmP6RaWSAEUCfbgyrtAXwQgTBJyKFYBjySdcDaj0EEJjOgmtDubnrDSnbPXNzUghIXkYLbq6GGWxvtxHnNW9Um7VzJFTr1ZqVRC/Q0JVpYFLZR5SvyDVaGmU8ViYoEKRcD/eQMG34cdE8/lDYACTo9LAAx+NKFuWkKPHOyMlTnGbPrQYqF3FNRFJWPidYbITZpsPT0F8/N/PsLM1ubLJSPUbNqxJOEIy0juH1WizZeub/L8PErND+iiWoX2lIcSqEheYBwBTA3V0dHrbdGXDuYgZ6dnUXFuxjYGTt8IoD6Yelp+zyyk78Sz1umj2VrzS9QzbvWo0f0hmVMDZzoxdn8OWJWrtr8HkpCkXnLhIL9qQytgmFqYDHl4bg5rzxDw96bADo/iu4h7evWA5Cb32mhS7VfwDtn8Pd+XKI2rSvTzpypm2JO8BveMfgJWqbw List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Siddharth, On 7/8/26 18:52, Siddharth Kothari wrote: > Hi hackers, > > Adding Melanie and Tomas to this thread. I noticed you both recently > committed similar changes to handle shared memory instrumentation > separation and retrieval for IndexScan/IndexOnlyScan (dd78e69cfc > dd78e69cfc337f93cfc0303ddf660262d7f1237e>) and SeqScan (3b1117d6e2 > commit/3b1117d6e2e47d86cdbd978b79434c630cb0ef52>). > > My patch implements the exact same pattern for CustomScan states. It > adds an optional RetrieveInstrumentationCustomScan hook so that > extensions can aggregate their worker metrics before the DSM gets > unlinked, bringing custom scans to parity with the recent core scan > instrumentation improvements. > > Could you please help review? > > The CommitFest entry is also updated here: https:// > commitfest.postgresql.org/patch/6524/ commitfest.postgresql.org/patch/6524/> > Thanks for the patch, and sorry for not responding earlier. The last couple months were incredibly busy, both because of the last commitfest and personal reasons. I think the patch looks generally OK, except for two things: 1) It needs to add the new callback to doc/src/sgml/custom-scan.sgml, with similar documentation as for the other callbacks. 2) While looking at execParallel.c it occurred to me the CustomScan may have the same issue as described in [1] (and a couple messages after that). The scan may in the parallel part of a plan, but not necessarily parallel-aware. But a lot of the initialization is gated by if (planstate->plan->parallel_aware) ... All the other scans initialize some of the instrumentation always, in blocks like this: /* even when not parallel-aware, for EXPLAIN ANALYZE */ And BHS had this issue until 9c18b47e610, but we didn't do the same thing for CustomScan. I guess we should. Of course, it's not the fault of this patch, it's just something I noticed while looking at the code. OTOH it probably also makes sense for CustomScan to handle the instrumentation just like the other scans, i.e. by allocating a separate DSM for the instrumentation. AFAICS that'll require a couple more optional callbacks in CustomExecMethods: ExecCustomScanInstrumentEstimate ExecCustomScanInstrumentInitDSM ExecCustomScanInstrumentInitWorker But I think that's OK. [1] https://www.postgresql.org/message-id/3bdbc70d-ad44-494a-8aab-868b5066fe8b%40vondra.me regards -- Tomas Vondra