Re: Assertion failure with LEFT JOINs among >500 relations

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Fri, 9 Oct 2020 at 15:06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I notice there are some other ad-hoc isnan() checks scattered
>> about costsize.c, too. Maybe we should indeed consider fixing
>> clamp_row_estimate to get rid of inf (and nan too, I suppose)
>> so that we'd not need those. I don't recall the exact cases
>> that made us introduce those checks, but they were for cases
>> a lot more easily reachable than this one, I believe.

> Is there actually a case where nrows could be NaN? If not, then it
> seems like a wasted check. Wouldn't it take one of the input
> relations or the input rels to have an Inf row estimate (which won't
> happen after changing clamp_row_estimate()), or the selectivity
> estimate being NaN.

I'm fairly certain that every one of the existing NaN checks was put
there on the basis of hard experience. Possibly digging in the git
history would offer more info about exactly where the NaNs came from.

regards, tom lane