Re: How the Planner in PGStrom differs from PostgreSQL? - Mailing list pgsql-general

Sorry, I got the question a week before from the sender but couldn't respond timely.

> I am reading through Postgres and PGStrom. Regarding the planning factors,
> I need some clarifications. Can u help me with that?
>
> Planner in Postgres checks for different scan and join methods, and then
> find the cheapest one and creates a query plan tree. While going for same
> thing in GPU, the checks should also be made for, whether it is device
> executable or not and the query plan tree from Postgres has been updated.
>
> How this planning in GPU actually works for? How to determine device
> executables? What are the factors considered for the planner in GPU?
>
PostgreSQL v9.5 newly adds custom-scan interface that allows extensions
to add its own path prior to selection of the cheapest path.
What PG-Strom generally does is (1) check whether the scan qualifier can
be executable on GPU device, (2) if yes, construct a CustomScanPath with
estimated cost value, (3) then, add_path() to register the CustomScanPath
node.
If cost of CustomScanPath is cheaper than others, it shall be chosen.
Its logic is same with a case when planner choose either of SeqScan or
IndexScan.

> For example, in gpujoin.c, the function responsible for this plan is
> pgstrom_post_planner_gpujoin. What is the work of this function? What is
> this actually doing?  It is updating some target list. What are they? It
> is checking for pgstrom_device_expression(tle->expr) i.e., for device
> executables. What are the tasks covered under this?
>
That is an ad-hoc surgical operation on the plan-tree once constructed.
It shall be removed in the v9.6 based implementation because of planner
infrastructure improvement.

In v9.5, we cannot attach general expression node on the target-list
of the plan-node under the create_plan_recurse(), thus, PG-Strom cannot
determine how device-side projection works. So, it hooks planner_hook
to adjust the plan tree. For example, if final target list contains
something like (x * y - z), it is more reasonable to reference the result
of calculated result in GPU rather than returning 3 attributed from GPU
and calculating on CPU.

Unlike your expectation, pgstrom_post_planner_gpujoin() does not perform
primary role on GPU path construction. I'd like to follow the code path
from the gpujoin_add_join_path().

Best regards,

> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Mark Anns
> Sent: Thursday, November 10, 2016 4:12 PM
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] How the Planner in PGStrom differs from PostgreSQL?
>
> I am reading through Postgres and PGStrom. Regarding the planning factors,
> I need some clarifications. Can u help me with that?
>
> Planner in Postgres checks for different scan and join methods, and then
> find the cheapest one and creates a query plan tree. While going for same
> thing in GPU, the checks should also be made for, whether it is device
> executable or not and the query plan tree from Postgres has been updated.
>
> How this planning in GPU actually works for? How to determine device
> executables? What are the factors considered for the planner in GPU?
>
> For example, in gpujoin.c, the function responsible for this plan is
> pgstrom_post_planner_gpujoin. What is the work of this function? What is
> this actually doing?  It is updating some target list. What are they? It
> is checking for pgstrom_device_expression(tle->expr) i.e., for device
> executables. What are the tasks covered under this?
>
> Best regards
>
>
>
> --
> View this message in context:
> http://postgresql.nabble.com/How-the-Planner-in-PGStrom-differs-from-P
> ostgreSQL-tp5929724.html
> Sent from the PostgreSQL - general mailing list archive at Nabble.com.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make
> changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general