From c89d507649df9fbc21617e02ab4d5e765a28b7df Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 3 Jul 2016 14:53:37 -0400
Subject: [PATCH] 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.
---
 src/backend/optimizer/path/costsize.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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;
-- 
GitLab