Skip to content

Commit 0c2c0f8

Browse files
committed
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.
1 parent fd26237 commit 0c2c0f8

File tree

1 file changed

+8
-0
lines changed

1 file changed

+8
-0
lines changed

src/backend/utils/adt/selfuncs.c

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3092,6 +3092,14 @@ estimate_num_groups(PlannerInfo *root, List *groupExprs, double input_rows)
30923092
double numdistinct;
30933093
ListCell *l;
30943094

3095+
/*
3096+
* We don't ever want to return an estimate of zero groups, as that tends
3097+
* to lead to division-by-zero and other unpleasantness. The input_rows
3098+
* estimate is usually already at least 1, but clamp it just in case it
3099+
* isn't.
3100+
*/
3101+
input_rows = clamp_row_est(input_rows);
3102+
30953103
/*
30963104
* If no grouping columns, there's exactly one group. (This can't happen
30973105
* for normal cases with GROUP BY or DISTINCT, but it is possible for

0 commit comments

Comments
 (0)