On Sat, Jan 14, 2017 at 12:07 AM, Robert Haas <[email protected]> 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
--
Sent via pgsql-committers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
