Re: [v9.5] Custom Plan API

From: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "Stephen Frost" <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)2ndquadrant(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, Jim Mlodgenski <jimmy76(at)gmail(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>
Subject: Re: [v9.5] Custom Plan API
Date: 2014-09-29 08:48:27
Message-ID: 9A28C8860F777E439AA12E8AEA7694F801044C0A@BPXM15GP.gisp.nec.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Wed, Sep 17, 2014 at 7:40 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> > At this moment, I revised the above portion of the patches.
> > create_custom_plan() was modified to call "PlanCustomPath" callback
> > next to the initialization of tlist and clauses.
> >
> > It's probably same as what you suggested.
>
> create_custom_plan() is mis-named. It's actually only applicable to the
> custom-scan case, because it's triggered by create_plan_recurse() getting
> a path node with a T_CustomScan pathtype. Now, we could change that;
> although in general create_plan_recurse() dispatches on pathtype, we could
> make CustomPath an exception; the top of that function could say if
> (IsA(best_path, CustomPath)) { /* do custom stuff */ }. But the problem
> with that idea is that, when the custom path is specifically a custom scan,
> rather than a join or some other thing, you want to do all of the same
> processing that's in create_scan_plan().
>
> So I think what should happen is that create_plan_recurse() should handle
> T_CustomScan the same way it handles T_SeqScan, T_IndexScan, et
> al: by calling create_scan_plan(). The switch inside that function can
> then call a function create_customscan_plan() if it sees T_CustomScan. And
> that function will be simpler than the
> create_custom_plan() that you have now, and it will be named correctly,
> too.
>
Fixed, according to what you suggested. It seems to me create_customscan_plan()
became more simplified than before.
Probably, it will minimize the portion of special case handling if CustomScan
with scanrelid==0 replaces built-in join plan in the future version.

> In ExplainNode(), I think sname should be set to "Custom Scan", not "Custom".
> And further down, the custom_name should be printed as "Custom Plan
> Provider" not just "Custom".
>
Fixed. I added an additional regression test to check EXPLAIN output
if not a text format.

> setrefs.c has remaining handling for the scanrelid = 0 case; please remove
> that.
>
Sorry, I removed it, and checked the patch again to ensure here is no similar
portions.

Thanks for your reviewing.
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

Attachment Content-Type Size
pgsql-v9.5-custom-scan.part-3.v11.patch application/octet-stream 47.0 KB
pgsql-v9.5-custom-scan.part-2.v11.patch application/octet-stream 43.6 KB
pgsql-v9.5-custom-scan.part-1.v11.patch application/octet-stream 10.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2014-09-29 09:10:24 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Previous Message Abhijit Menon-Sen 2014-09-29 08:39:01 initdb -S and tablespaces