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
-
Fix failure to use clamp_row_est() for parallel joins.
- 5feb78ae885c 9.6.3 landed
- 1ea60ad602f9 10.0 landed
-
Fix cardinality estimates for parallel joins.
- 2d443ae1b012 9.6.2 cited