Re: Assertion failure with LEFT JOINs among >500 relations - Mailing list pgsql-hackers

From David Rowley
Subject Re: Assertion failure with LEFT JOINs among >500 relations
Date
Msg-id CAApHDvqiHj3rJZDo1yh-a+bdSJeLZwc6zAACS_9dYPrBuM1Qbg@mail.gmail.com
Whole thread Raw
In response to Re: Assertion failure with LEFT JOINs among >500 relations  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Assertion failure with LEFT JOINs among >500 relations
List pgsql-hackers
On Sat, 17 Oct 2020 at 06:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm confused now, because the v2 patch does remove those isnan calls?

I think that was a case of a last-minute change of mind and forgetting
to attach the updated patch.

> I rechecked the archives, and I agree that there's no data about
> exactly how we could have gotten a NaN here.  My guess though is
> infinity-times-zero in some earlier relation size estimate.  So
> hopefully the clamp to 1e100 will make that impossible, or if it
> doesn't then clamp_row_est() should still prevent a NaN from
> propagating to the next level up.
>
> I'm good with the v2 patch.

Thanks a lot for having a look. I'll proceed in getting the v2 which I
sent earlier into master.

For the backbranches, I think I go with something more minimal in the
form of adding:

if (outer_path_rows <= 0 || isnan(outer_path_rows))
    outer_path_rows = 1;
+else if (isinf(outer_path_rows))
+    outer_path_rows = DBL_MAX;

and the same for the inner_path_rows to each area in costsize.c which
has that code.

Wondering your thoughts on that.

David



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Sometimes the output to the stdout in Windows disappears
Next
From: David Rowley
Date:
Subject: Re: jit and explain nontext