Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>
Subject: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Date: 2015-02-13 07:37:42
Message-ID: CAB7nPqSaEsrXLJGvK=TJFx-ZsYKzQhTB16zVMQedHF--xSeksA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 15, 2015 at 8:02 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:

> > On Fri, Jan 9, 2015 at 10:51 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
> wrote:
> > > When custom-scan node replaced a join-plan, it shall have at least two
> > > child plan-nodes. The callback handler of PlanCustomPath needs to be
> > > able to call create_plan_recurse() to transform the underlying
> > > path-nodes to plan-nodes, because this custom-scan node may take other
> > > built-in scan or sub-join nodes as its inner/outer input.
> > > In case of FDW, it shall kick any underlying scan relations to remote
> > > side, thus we may not expect ForeignScan has underlying plans...
> >
> > Do you have an example of this?
> >
> Yes, even though full code set is too large for patch submission...
>
> https://github.com/pg-strom/devel/blob/master/src/gpuhashjoin.c#L1880
>
> This create_gpuhashjoin_plan() is PlanCustomPath callback of GpuHashJoin.
> It takes GpuHashJoinPath inherited from CustomPath that has multiple
> underlying scan/join paths.
> Once it is called back from the backend, it also calls
> create_plan_recurse()
> to make inner/outer plan nodes according to the paths.
>
> In the result, we can see the following query execution plan that
> CustomScan
> takes underlying scan plans.
>
> postgres=# EXPLAIN SELECT * FROM t0 NATURAL JOIN t1 NATURAL JOIN t2;
> QUERY PLAN
>
> ----------------------------------------------------------------------------------
> Custom Scan (GpuHashJoin) (cost=2968.00..140120.31 rows=3970922
> width=143)
> Hash clause 1: (aid = aid)
> Hash clause 2: (bid = bid)
> Bulkload: On
> -> Custom Scan (GpuScan) on t0 (cost=500.00..57643.00 rows=4000009
> width=77)
> -> Custom Scan (MultiHash) (cost=734.00..734.00 rows=40000 width=37)
> hash keys: aid
> nBatches: 1 Buckets: 46000 Memory Usage: 99.99%
> -> Seq Scan on t1 (cost=0.00..734.00 rows=40000 width=37)
> -> Custom Scan (MultiHash) (cost=734.00..734.00 rows=40000
> width=37)
> hash keys: bid
> nBatches: 1 Buckets: 46000 Memory Usage: 49.99%
> -> Seq Scan on t2 (cost=0.00..734.00 rows=40000 width=37)
> (13 rows)
>

Where are we on this? AFAIK, we have now a feature with no documentation
and no example in-core to test those custom routine APIs, hence moved to
next CF.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-02-13 07:40:40 Re: ctidscan as an example of custom-scan (Re: [v9.5] Custom Plan API)
Previous Message Michael Paquier 2015-02-13 07:35:22 Re: documentation update for doc/src/sgml/func.sgml