Re: why not parallel seq scan for slow functions

On Mon, Aug 21, 2017 at 3:15 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 21 August 2017 at 10:08, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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