Re: [GENERAL] How the Planner in PGStrom differs from PostgreSQL?

[Kouhei Kaigai]

> On Thu, Nov 17, 2016 at 7:09 PM, Mark Anns  wrote:
> >  Can u explain this statement "check whether the scan qualifier can be
> > executable on GPU device"
> >
> > What are the scan qualifiers?
> >
> > How to determine whether they are device executable or not?
> >
> > The cost estimates are entirely based on number of rows and type of scan.
> > Then it will be same for both CPU and GPU. How the decision can be
> > made for cheaper one comparing CPU and GPU estimates?
> 
> There is a parameter (call it a "factor" if you will) called cpu_tuple_cost
> (section 19.7.2 Planner Cost Constants in the PostgreSQL documentation;
> link at the bottom), which "sets the planner's estimate of the cost of
> processing each row during a query"
> as the description on that page says.
>
> With that as the unit of cost of processing rows using the CPU and considering
> any differences in the processing capabilities between CPU and GPU, the
> optimizer code will cost the portion of plan that will be processed by the
> GPU (typically a table scan or a join) as some fraction of the cost of
> executing the same portion of the plan using the traditional CPU processing.
> 
> (Kaigai-san will be better able to explain and correct if the above rough
> sketch is not exactly accurate)
>
It is right introduction.

PG-Strom assumes GPU can run functions/operators within scan qualifier
more effectively than CPU, but has more startup cost (const) and extra
data copy via PCI-E bus (another factor based on width x num rows).
These factor makes differences in the cost of individual scan/join paths,
then planner will choose the appropriate one.

Thanks,

PG-Strom Project / NEC OSS Promotion Center
KaiGai Kohei 

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] How the Planner in PGStrom differs from PostgreSQL?

[Kouhei Kaigai]

>  Can u explain this statement "check whether the scan qualifier can be
> executable on GPU device"
> 
> What are the scan qualifiers?
> 
SELECT * FROM my_table WHERE x > 20 AND memo LIKE '%abc%';
 
This is scan qualifier.

> How to determine whether they are device executable or not?
>
If all the function (or function on behalf of operator) are
available to transform GPU source code. Please see codegen.c.

> The cost estimates are entirely based on number of rows and type of scan.
> Then it will be same for both CPU and GPU. How the decision can be made
> for cheaper one comparing CPU and GPU estimates?
>
If Scan path has any scan qualifier, its cost to evaluate depends on
the device type. PG-Strom assumes GPU has larger startup cost but
less cost per tuple. So, GpuScan path is tend to be choosen if number
of rows are relatively large.

Thanks,
--
The PG-Strom Project / NEC OSS Promotion Center
KaiGai Kohei 


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] How the Planner in PGStrom differs from PostgreSQL?

[Kouhei Kaigai]

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-ow...@postgresql.org
> [mailto:pgsql-general-ow...@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


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general