From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Onder Kalaci <onderk(at)microsoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Assertion failure with LEFT JOINs among >500 relations |
Date: | 2020-10-18 21:01:00 |
Message-ID: | CAApHDvqiHj3rJZDo1yh-a+bdSJeLZwc6zAACS_9dYPrBuM1Qbg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 17 Oct 2020 at 06:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2020-10-18 22:20:16 | Re: jit and explain nontext |
Previous Message | Tom Lane | 2020-10-18 18:38:14 | Re: Sometimes the output to the stdout in Windows disappears |