Re: BUG #18429: Inconsistent results on similar queries with join lateral

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #18429: Inconsistent results on similar queries with join lateral
Дата
Msg-id 742265.1713190833@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #18429: Inconsistent results on similar queries with join lateral  (Richard Guo <guofenglinux@gmail.com>)
Ответы Re: BUG #18429: Inconsistent results on similar queries with join lateral  (Corey Huinker <corey.huinker@gmail.com>)
Список pgsql-bugs
Richard Guo <guofenglinux@gmail.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



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: BUG #18437: The index scan result is more than the full scan result, and the primary key index has duplicate val
Следующее
От: Robert Haas
Дата:
Сообщение: Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune()