On Tue, 18 Jun 2024 at 14:23, Kohei KaiGai <kai...@heterodb.com> wrote: > > 2024年6月17日(月) 8:27 David Rowley <dgrowle...@gmail.com>: > > It would be good to know what type of Path outer_path is. Normally > > we'll clamp_row_est() on that field. I suspect we must have some Path > > type that isn't doing that. > > > > KaiGai-san, what type of Path is outer_path? > > > It is CustomPath with rows = 3251872.916666667.
I suspected this might have been a CustomPath. > (I'm not certain whether the non-integer value in the estimated rows > is legal or not.) I guess since it's not documented that Path.rows is always clamped, it's probably bad to assume that it is. Since clamp_row_est() will ensure the value is clamped >= 1.0 && <= MAXIMUM_ROWCOUNT (which ensures non-zero), I tried looking around the codebase for anything that divides by Path.rows to see if we ever assume that we can divide without first checking if Path.rows != 0. Out of the places I saw, it seems we do tend to code things so that we don't assume the value has been clamped. E.g. adjust_limit_rows_costs() does if (*rows < 1) *rows = 1; I think the best solution is to apply the attached. I didn't test, but it should fix the issue you reported and also ensure that MemoizePath.calls is never zero, which would also cause issues in the hit_ratio calculation in cost_memoize_rescan(). David
clamp_row_est_memoize_calls.patch
Description: Binary data
