From: Tom Lane Date: Sun, 3 Jul 2016 18:53:37 +0000 (-0400) Subject: Round rowcount estimate for a partial path to an integer. X-Git-Tag: REL9_6_BETA3~66 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=c89d507649df9fbc21617e02ab4d5e765a28b7df;p=postgresql 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. --- diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c index c4422fe986..1c20edcdfe 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;