mirror of
				https://github.com/postgres/postgres.git
				synced 2025-10-31 00:03:57 -04:00 
			
		
		
		
	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.
This commit is contained in:
		
							parent
							
								
									477b5a0e24
								
							
						
					
					
						commit
						69cc60dcfd
					
				| @ -3209,6 +3209,14 @@ estimate_num_groups(PlannerInfo *root, List *groupExprs, double input_rows) | ||||
| 	double		numdistinct; | ||||
| 	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 | ||||
|  | ||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user