diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2016-07-03 14:53:37 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2016-07-03 14:53:46 -0400 |
| commit | c89d507649df9fbc21617e02ab4d5e765a28b7df (patch) | |
| tree | a6cc92d04c3f43715b10bcd37470ed420ca16be4 /src | |
| parent | 3a4a33ad49e7887b104a29323e4ea625d164a139 (diff) | |
| download | postgresql-c89d507649df9fbc21617e02ab4d5e765a28b7df.tar.gz postgresql-c89d507649df9fbc21617e02ab4d5e765a28b7df.zip | |
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.
Diffstat (limited to 'src')
| -rw-r--r-- | src/backend/optimizer/path/costsize.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c index c4422fe9860..1c20edcdfeb 100644 --- a/src/backend/optimizer/path/costsize.c +++ b/src/backend/optimizer/path/costsize.c @@ -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; |