From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
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-08 23:59:15 |
Message-ID: | 2664789.1602201555@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> I admit it's annoying to add cycles to clamp_row_est() for such insane cases.
I poked at this a bit more closely, and noted that the actual problem is
that when we do this:
outer_skip_rows = rint(outer_path_rows * outerstartsel);
we have outer_path_rows = inf, outerstartsel = 0, and of course inf times
zero is NaN. So we end up asserting "NaN <= Inf", not "Inf <= Inf"
(which wouldn't have caused a problem).
If we did want to do something here, I'd consider something like
if (isnan(outer_skip_rows))
outer_skip_rows = 0;
if (isnan(inner_skip_rows))
inner_skip_rows = 0;
(We shouldn't need that for outer_rows/inner_rows, since the endsel
values can't be 0.) Messing with clamp_row_est would be a much more
indirect way of fixing it, as well as having more widespread effects.
In the end though, I'm still not terribly excited about this.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2020-10-09 00:14:24 | Re: [HACKERS] logical decoding of two-phase transactions |
Previous Message | Michael Paquier | 2020-10-08 23:52:50 | Re: Minor documentation error regarding streaming replication protocol |