Re: Schedule for 9.5alpha1 - Mailing list pgsql-hackers

> On Thu, Jun 25, 2015 at 11:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> > On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai <kaigai@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.
> >>
> >> 9A28C8860F777E439AA12E8AEA7694F8010F3EA6@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.48rows=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.00rows=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 <kaigai@ak.jp.nec.com>