> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Robert Haas > Sent: Monday, February 20, 2017 2:20 AM > To: Kaigai Kouhei(海外 浩平) <[email protected]> > Cc: Claudio Freire <[email protected]>; Amit Kapila > <[email protected]>; pgsql-hackers <[email protected]> > Subject: Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside > ExecEndGather) > > On Fri, Feb 17, 2017 at 12:46 PM, Kouhei Kaigai <[email protected]> > wrote: > > The attached patch is revised one. > > > > Invocation of Exec(Foreign|Custom)ParallelFinish was moved to > > ExecParallelRetrieveInstrumentation() not to walk on the plan- state > > tree twice. > > One (hypothetical) downside is, FDW/CSP can retrieve its own run-time > > statistics only when query is executed under EXPLAIN ANALYZE. > > > > This enhancement allows FDW/CSP to collect its specific run- time > > statistics more than Instrumentation, then show them as output of > > EXPLAIN. My expected examples are GPU's kernel execution time, DMA > > transfer ratio and so on. These statistics will never appear in the > > Instrumentation structure, however, can be a hot- point of performance > > bottleneck if CustomScan works on background workers. > > Would gather_shutdown_children_first.patch from > https://www.postgresql.org/message-id/CAFiTN-s5KuRuDrQCEpiHHzmVf7JTtbn > [email protected] > help with this problem also? Suppose we did that, and then also added an > ExecShutdownCustom method. Then you'd definitely be able to get control > before the DSM went away, either from ExecEndNode() or ExecShutdownNode(). > Ah, yes, I couldn't find any problem around the above approach. ExecShutdownGather() can be called by either ExecShutdownNode() or ExecEndGather(). This patch allows to have an entrypoint for CSP/FDW prior to release of the DSM.
Thanks, ---- PG-Strom Project / NEC OSS Promotion Center KaiGai Kohei <[email protected]> -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
