aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/selfuncs.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2013-05-10 17:15:43 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2013-05-10 17:15:43 -0400
commit0c2c0f82c2cd6d2fa83955e9d767059639010ffc (patch)
tree6545d5e69336f87b0a10c41ed031f2689e58204f /src/backend/utils/adt/selfuncs.c
parentfd262376e9d81f77bde73ab70fa9abdcbc9c6199 (diff)
downloadpostgresql-0c2c0f82c2cd6d2fa83955e9d767059639010ffc.tar.gz
postgresql-0c2c0f82c2cd6d2fa83955e9d767059639010ffc.zip
Guard against input_rows == 0 in estimate_num_groups().
This case doesn't normally happen, because the planner usually clamps all row estimates to at least one row; but I found that it can arise when dealing with relations excluded by constraints. Without a defense, estimate_num_groups() can return zero, which leads to divisions by zero inside the planner as well as assertion failures in the executor. An alternative fix would be to change set_dummy_rel_pathlist() to make the size estimate for a dummy relation 1 row instead of 0, but that seemed pretty ugly; and probably someday we'll want to drop the convention that the minimum rowcount estimate is 1 row. Back-patch to 8.4, as the problem can be demonstrated that far back.
Diffstat (limited to 'src/backend/utils/adt/selfuncs.c')
-rw-r--r--src/backend/utils/adt/selfuncs.c8
1 files changed, 8 insertions, 0 deletions
diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c
index abeef769baa..1436ce435f3 100644
--- a/src/backend/utils/adt/selfuncs.c
+++ b/src/backend/utils/adt/selfuncs.c
@@ -3093,6 +3093,14 @@ estimate_num_groups(PlannerInfo *root, List *groupExprs, double input_rows)
ListCell *l;
/*
+ * We don't ever want to return an estimate of zero groups, as that tends
+ * to lead to division-by-zero and other unpleasantness. The input_rows
+ * estimate is usually already at least 1, but clamp it just in case it
+ * isn't.
+ */
+ input_rows = clamp_row_est(input_rows);
+
+ /*
* If no grouping columns, there's exactly one group. (This can't happen
* for normal cases with GROUP BY or DISTINCT, but it is possible for
* corner cases with set operations.)