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@xxxxxxxxxxxxxx > [mailto:pgsql-general-owner@xxxxxxxxxxxxxx] On Behalf Of Mark Anns > Sent: Thursday, November 10, 2016 4:12 PM > To: pgsql-general@xxxxxxxxxxxxxx > Subject: 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@xxxxxxxxxxxxxx) To make > changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
