mirror of
https://git.postgresql.org/git/postgresql.git
synced 2025-03-01 19:45:33 +08:00
Round rowcount estimate for a partial path to an integer.
I'd been wondering why I was sometimes seeing fractional rowcount estimates in parallel-query situations, and this seems to be the reason. (You won't see the fractional parts in EXPLAIN, because it prints rowcounts with %.0f, but they are apparent in the debugger.) A fractional rowcount is not any saner for a partial path than any other kind of path, and it's equally likely to break cost estimation for higher paths, so apply clamp_row_est() like we do in other places.
This commit is contained in:
parent
3a4a33ad49
commit
c89d507649
@ -263,7 +263,7 @@ cost_seqscan(Path *path, PlannerInfo *root,
|
||||
* because they'll anticipate receiving more rows than any given copy
|
||||
* will actually get.
|
||||
*/
|
||||
path->rows /= parallel_divisor;
|
||||
path->rows = clamp_row_est(path->rows / parallel_divisor);
|
||||
|
||||
/* The CPU cost is divided among all the workers. */
|
||||
cpu_run_cost /= parallel_divisor;
|
||||
|
Loading…
Reference in New Issue
Block a user