Re: assertion failure at cost_memoize_rescan()
От | David Rowley |
---|---|
Тема | Re: assertion failure at cost_memoize_rescan() |
Дата | |
Msg-id | CAApHDvq=pPqa-=Wrmt_-EZt1=YTO+EtgFzG4Rbi381Rz9zBacg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: assertion failure at cost_memoize_rescan() (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: assertion failure at cost_memoize_rescan()
|
Список | pgsql-hackers |
On Mon, 17 Jun 2024 at 10:23, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: > Interesting. Seems like a bug due to the two places clamping the values > inconsistently. It probably does not matter in other contexts because we > don't subtract the values like this, but here it triggers the assert. > > I guess the simplest fix would be to clamp "calls" the same way before > calculating hit_ratio. That makes the ">= 0" part of the assert somewhat > pointless, though. "calls" comes from the value passed as the final parameter in create_memoize_path(). There's really only one call to that function and that's in get_memoize_path(). return (Path *) create_memoize_path(root, innerrel, inner_path, param_exprs, hash_operators, extra->inner_unique, binary_mode, outer_path->rows); 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? David David
В списке pgsql-hackers по дате отправления: