Re: [COMMITTERS] pgsql: Fix cardinality estimates for parallel joins. - Mailing list pgsql-committers

From Amit Kapila
Subject Re: [COMMITTERS] pgsql: Fix cardinality estimates for parallel joins.
Date
Msg-id CAA4eK1KPm8RYa1Kun3ZmQj9pb723b-EFN70j47Pid1vn3ByquA@mail.gmail.com
Whole thread Raw
In response to [COMMITTERS] pgsql: Fix cardinality estimates for parallel joins.  (Robert Haas <rhaas@postgresql.org>)
List pgsql-committers
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?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


pgsql-committers by date:

Previous
From: Fujii Masao
Date:
Subject: [COMMITTERS] pgsql: Fix typos in comments.
Next
From: Magnus Hagander
Date:
Subject: [COMMITTERS] pgsql: Make pg_basebackup use temporary replication slots