From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Robert Haas <rhaas(at)postgresql(dot)org> |
Cc: | pgsql-committers <pgsql-committers(at)postgresql(dot)org> |
Subject: | Re: pgsql: Fix cardinality estimates for parallel joins. |
Date: | 2017-01-16 12:23:52 |
Message-ID: | CAA4eK1KPm8RYa1Kun3ZmQj9pb723b-EFN70j47Pid1vn3ByquA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Sat, Jan 14, 2017 at 12:07 AM, Robert Haas <rhaas(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2017-01-16 12:58:31 | pgsql: Make pg_basebackup use temporary replication slots |
Previous Message | Fujii Masao | 2017-01-16 09:56:14 | pgsql: Fix typos in comments. |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-01-16 12:46:46 | Re: Support for pg_receivexlog --format=plain|tar |
Previous Message | Magnus Hagander | 2017-01-16 12:12:23 | Re: Support for pg_receivexlog --format=plain|tar |