Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
От | Michael Paquier |
---|---|
Тема | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) |
Дата | |
Msg-id | CAB7nPqSaEsrXLJGvK=TJFx-ZsYKzQhTB16zVMQedHF--xSeksA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Список | pgsql-hackers |
<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Thu, Jan 15, 2015 at 8:02 AM, Kouhei Kaigai<span dir="ltr"><<a href="mailto:kaigai@ak.jp.nec.com" target="_blank">kaigai@ak.jp.nec.com</a>></span> wrote:<br/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>On Fri, Jan 9, 2015 at 10:51 AM, Kouhei Kaigai <<a href="mailto:kaigai@ak.jp.nec.com">kaigai@ak.jp.nec.com</a>>wrote:<br /> > > When custom-scan node replaced a join-plan,it shall have at least two<br /> > > child plan-nodes. The callback handler of PlanCustomPath needs to be<br/> > > able to call create_plan_recurse() to transform the underlying<br /> > > path-nodes to plan-nodes,because this custom-scan node may take other<br /> > > built-in scan or sub-join nodes as its inner/outerinput.<br /> > > In case of FDW, it shall kick any underlying scan relations to remote<br /> > > side,thus we may not expect ForeignScan has underlying plans...<br /> ><br /> > Do you have an example of this?<br/> ><br /></span>Yes, even though full code set is too large for patch submission...<br /><br /><a href="https://github.com/pg-strom/devel/blob/master/src/gpuhashjoin.c#L1880" target="_blank">https://github.com/pg-strom/devel/blob/master/src/gpuhashjoin.c#L1880</a><br/><br /> This create_gpuhashjoin_plan()is PlanCustomPath callback of GpuHashJoin.<br /> It takes GpuHashJoinPath inherited from CustomPaththat has multiple<br /> underlying scan/join paths.<br /> Once it is called back from the backend, it also callscreate_plan_recurse()<br /> to make inner/outer plan nodes according to the paths.<br /><br /> In the result, we cansee the following query execution plan that CustomScan<br /> takes underlying scan plans.<br /><br /> postgres=# EXPLAINSELECT * FROM t0 NATURAL JOIN t1 NATURAL JOIN t2;<br /> QUERY PLAN<br /> ----------------------------------------------------------------------------------<br/> Custom Scan (GpuHashJoin) (cost=2968.00..140120.31rows=3970922 width=143)<br /> Hash clause 1: (aid = aid)<br /> Hash clause 2: (bid = bid)<br/> Bulkload: On<br /> -> Custom Scan (GpuScan) on t0 (cost=500.00..57643.00 rows=4000009 width=77)<br /> -> Custom Scan (MultiHash) (cost=734.00..734.00 rows=40000 width=37)<br /> hash keys: aid<br /> nBatches: 1 Buckets: 46000 Memory Usage: 99.99%<br /> -> Seq Scan on t1 (cost=0.00..734.00 rows=40000width=37)<br /> -> Custom Scan (MultiHash) (cost=734.00..734.00 rows=40000 width=37)<br /> hash keys: bid<br /> nBatches: 1 Buckets: 46000 Memory Usage: 49.99%<br /> -> Seq Scan on t2 (cost=0.00..734.00 rows=40000 width=37)<br /> (13 rows)<br /></blockquote></div><br /></div><div class="gmail_extra">Whereare we on this? AFAIK, we have now a feature with no documentation and no example in-core to testthose custom routine APIs, hence moved to next CF.<br />-- <br /><div class="gmail_signature">Michael<br /></div></div></div>
В списке pgsql-hackers по дате отправления: