Re: [COMMITTERS] pgsql: Fix cardinality estimates for parallel joins.

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-01-17T16:49:44Z
Lists: pgsql-hackers
On Mon, Jan 16, 2017 at 7:23 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Sat, Jan 14, 2017 at 12:07 AM, Robert Haas <rhaas@postgresql.org> wrote:
>> Fix cardinality estimates for parallel joins.
>>
>
> +       /*
> +        * In the case of a parallel plan, the row count needs to represent
> +        * the number of tuples processed per worker.
> +        */
> +       path->rows = clamp_row_est(path->rows / parallel_divisor);
>     }
>
>     path->startup_cost = startup_cost;
> @@ -2014,6 +1996,10 @@ final_cost_nestloop(PlannerInfo *root, NestPath *path,
>     else
>         path->path.rows = path->path.parent->rows;
>
> +   /* For partial paths, scale row estimate. */
> +   if (path->path.parallel_workers > 0)
> +       path->path.rows /= get_parallel_divisor(&path->path);
>
>
> Isn't it better to call clamp_row_est in join costing functions as we
> are doing in cost_seqscan()?  Is there a reason to keep those
> different?

No, those should probably be changed to match.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Commits

  1. Fix failure to use clamp_row_est() for parallel joins.

  2. Fix cardinality estimates for parallel joins.