From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | Benoit Ryder <b(dot)ryder(at)ateme(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #18429: Inconsistent results on similar queries with join lateral |
Date: | 2024-04-15 14:20:33 |
Message-ID: | 742265.1713190833@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> I agree that the new test case for v15 does not seem to be worth
> including in v16+. It seems to me that it would be better if we can
> have another new test case to verify that we've included child rel's
> em_relids even for appendrel child relations with pseudoconstant
> translated variables, i.e. to verify that the change in equivclass.c
> takes effect. Maybe with a query like below:
> explain (costs off)
> select * from tenk1 t1
> left join lateral
> (select t1.unique1 as t1u, 0 as c
> union all
> select t1.unique1 as t1u, 1 as c) s on true
> where t1.unique1 = s.c;
> Without the change in equivclass.c, this query would trigger the new
> added assert in get_baserel_parampathinfo for v16, and give a wrong plan
> for v15. What do you think?
I didn't add such a test because there are already several cases
(in foreign_data.sql, IIRC) that trigger the assert, which is
how come I found the problem in the first place. Admittedly,
those depend on potentially-changeable details of an
information_schema view, so maybe it'd be better to have a
bespoke test.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-04-15 16:17:22 | Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() |
Previous Message | Laurenz Albe | 2024-04-15 14:18:04 | Re: BUG #18437: The index scan result is more than the full scan result, and the primary key index has duplicate val |