Re: why not parallel seq scan for slow functions
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeff Janes <jeff.janes@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-21T10:42:53Z
Lists: pgsql-hackers
On Mon, Aug 21, 2017 at 3:15 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 21 August 2017 at 10:08, Amit Kapila <amit.kapila16@gmail.com> wrote: > >> Thoughts? > > This seems like a very basic problem for parallel queries. > > The problem seems to be that we are calculating the cost of the plan > rather than the speed of the plan. > > Clearly, a parallel task has a higher overall cost but a lower time to > complete if resources are available. > > We have the choice of 1) adding a new optimizable quantity, > I think this has the potential of making costing decisions difficult. I mean to say, if we include any such new parameter, then we need to consider that along with cost as we can't completely ignore the cost. > or of 2) > treating cost = speed, so we actually reduce the cost of a parallel > plan rather than increasing it so it is more likely to be picked. > Yeah, this is what is being currently followed for costing of parallel plans and this patch also tries to follow the same. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Rewrite the code that applies scan/join targets to paths.
- 11cf92f6e2e1 11.0 landed
-
Teach create_projection_plan to omit projection where possible.
- d7c19e62a8e0 11.0 landed
-
Make the upper part of the planner work by generating and comparing Paths.
- 3fc6e2d7f5b6 9.6.0 cited