On Mon, Aug 21, 2017 at 3:15 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 21 August 2017 at 10:08, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
