> On Thu, Jun 25, 2015 at 11:55 PM, Robert Haas <robertmh...@gmail.com> wrote:
> > On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote:
> >> I have a serious open item reported 1.5 month ago then reminded
> >> several times has not been fixed up yet.
> >>
> >> 9a28c8860f777e439aa12e8aea7694f8010f3...@bpxm15gp.gisp.nec.co.jp
> >>
> >> Patch is less than 100 lines, entirely designed according to Tom's
> >> suggestion.
> >>
> >> The problem is, commit 1a8a4e5cde2b7755e11bde2ea7897bd650622d3e reverted
> >> create_plan_recurse() to static function, thus, extension lost way to
> >> transform Path node to Plan node if it wants to takes underlying child
> >> nodes, like SeqScan, HashJoin and so on.
> >>
> >> Tom's suggestion is to add a list of Path nodes on CustomPath structure,
> >> to be transformed by createplan.c, instead of public create_plan_recurse().
> >>
> >> It is nearly obvious problem, and bugfix patch already exists.
> >
> > Yes, I am quite unhappy with this situation. Tom promised me at PGCon
> > that he would look at this soon, but there is no sign that he has, and
> > he said the same thing weeks ago. I think it can't be right to let
> > this sit for another month or three. Even if the API you've
> > implemented is worse than something Tom can design, it is certainly
> > better than the status quo. I would rather have a working but
> > imperfect API and have to break compatibility later in beta than have
> > a non-working API.
>
> ...given which, I have committed this. I did not like the use of
> custom_children as a generic monicker, so I changed it to
> custom_paths, custom_plans, or custom_ps, as appropriate in each case.
> I did a bit of cosmetic cleanup as well.
>
> This does seem much nicer than giving custom plans direct access to
> create_plan_recurse(). The fact that you found various other places
> of using those lists demonstrates that nicely.
>
Thanks for your help!
One advantage of the approach, I think, is custom_paths list allows to
implement N-way (N > 2) join more naturally than just direct accesses
to create_plan_recurse().
The example below shows contents of t1, t2 and t3 are enough small to
load GPU RAM, so the custom "GpuJoin" can run these 4 tables join within
a single step.
postgres=# explain select * from t0 natural join t1 natural join t2 natural
join t3;
QUERY PLAN
------------------------------------------------------------------------------------------------
Custom Scan (GpuJoin) (cost=6501.77..249476.48 rows=9899296 width=176)
Bulkload: On (density: 100.00%)
Depth 1: Logic: GpuHashJoin, HashKeys: (cid), JoinQual: (cid = cid),
nrows_ratio: 0.98995197
Depth 2: Logic: GpuHashJoin, HashKeys: (aid), JoinQual: (aid = aid),
nrows_ratio: 1.00000000
Depth 3: Logic: GpuHashJoin, HashKeys: (bid), JoinQual: (bid = bid),
nrows_ratio: 1.00000000
-> Custom Scan (BulkScan) on t0 (cost=0.00..242855.74 rows=9999774
width=77)
-> Seq Scan on t3 (cost=0.00..734.00 rows=40000 width=37)
-> Seq Scan on t1 (cost=0.00..734.00 rows=40000 width=37)
-> Seq Scan on t2 (cost=0.00..734.00 rows=40000 width=37)
(9 rows)
Best regards,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
