ParallelFinish-hook of FDW/CSP (Re: Steps inside ExecEndGather) - Mailing list pgsql-hackers
From | Kouhei Kaigai |
---|---|
Subject | ParallelFinish-hook of FDW/CSP (Re: Steps inside ExecEndGather) |
Date | |
Msg-id | 9A28C8860F777E439AA12E8AEA7694F801250675@BPXM15GP.gisp.nec.co.jp Whole thread Raw |
Responses |
Re: ParallelFinish-hook of FDW/CSP (Re: Steps inside ExecEndGather)
Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather) |
List | pgsql-hackers |
Hello, The attached patch implements the suggestion by Amit before. What I'm motivated is to collect extra run-time statistics specific to a particular ForeignScan/CustomScan, not only the standard Instrumentation; like DMA transfer rate or execution time of GPU kernels in my case. Per-node DSM toc is one of the best way to return run-time statistics to the master backend, because FDW/CSP can assign arbitrary length of the region according to its needs. It is quite easy to require. However, one problem is, the per-node DSM toc is already released when ExecEndNode() is called on the child node of Gather. This patch allows extensions to get control on the master backend's context when all the worker node gets finished but prior to release of the DSM segment. If FDW/CSP has its special statistics on the segment, it can move to the private memory area for EXPLAIN output or something other purpose. One design consideration is whether the hook shall be called from ExecParallelRetrieveInstrumentation() or ExecParallelFinish(). The former is a function to retrieve the standard Instrumentation information, thus, it is valid only if EXPLAIN ANALYZE. On the other hands, if we put entrypoint at ExecParallelFinish(), extension can get control regardless of EXPLAIN ANALYZE, however, it also needs an extra planstate_tree_walker(). Right now, we don't assume anything onto the requirement by FDW/CSP. It may want run-time statistics regardless of EXPLAIN ANALYZE, thus, hook shall be invoked always when Gather node confirmed termination of the worker processes. Thanks, -- NEC OSS Promotion Center / PG-Strom Project KaiGai Kohei <kaigai@ak.jp.nec.com> > -----Original Message----- > From: Amit Kapila [mailto:amit.kapila16@gmail.com] > Sent: Monday, October 17, 2016 11:22 AM > To: Kaigai Kouhei(海外 浩平) > Cc: Robert Haas; pgsql-hackers > Subject: ##freemail## Re: [HACKERS] Steps inside ExecEndGather > > On Mon, Oct 17, 2016 at 6:22 AM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote: > > Hello, > > > > I'm now trying to carry extra performance statistics on CustomScan > > (like DMA transfer rate, execution time of GPU kernels, etc...) > > from parallel workers to the leader process using the DSM segment > > attached by the parallel-context. > > We can require an arbitrary length of DSM using ExecCustomScanEstimate > > hook by extension, then it looks leader/worker can share the DSM area. > > However, we have a problem on this design. > > > > Below is the implementation of ExecEndGather(). > > > > void > > ExecEndGather(GatherState *node) > > { > > ExecShutdownGather(node); > > ExecFreeExprContext(&node->ps); > > ExecClearTuple(node->ps.ps_ResultTupleSlot); > > ExecEndNode(outerPlanState(node)); > > } > > > > It calls ExecShutdownGather() prior to the recursive call of ExecEndNode(). > > The DSM segment shall be released on this call, so child node cannot > > reference the DSM at the time of ExecEndNode(). > > > > Before releasing DSM, we do collect all the statistics or > instrumentation information of each node. Refer > ExecParallelFinish()->ExecParallelRetrieveInstrumentation(), so I am > wondering why can't you collect the additional information in the same > way? > > > -- > With Regards, > Amit Kapila. > EnterpriseDB: http://www.enterprisedb.com
Attachment
pgsql-hackers by date: