Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500

Поиск
Список
Период
Сортировка
От Richard Guo
Тема Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500
Дата
Msg-id CAMbWs49cnL7OcSfiyJ_VEKSYE1L5X7KjhOtVzSmkSauE89pLPQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

On Sun, Jan 7, 2024 at 6:41 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Lakhin <exclusion@gmail.com> writes:
> Please look at the following query:
> CREATE TABLE t(i int);
> INSERT INTO t VALUES (1);
> VACUUM ANALYZE t;

> WITH ir AS (INSERT INTO t VALUES (2) RETURNING i)
> SELECT * FROM ir WHERE i = 2;

> which produces ERROR:  no relation entry for relid 1
> starting from f7816aec2.

Nice catch.
 
Thanks for the report!  I guess we need something like the attached.

+1.
 
I'm surprised that this hasn't been noticed before; was the case
really unreachable before?

It seems that this case is only reachable with Vars of an INSERT target
relation, and it seems that there is no other way to reference such a
Var other than using CTE.

Thanks
Richard

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

Предыдущее
От: Geoff Winkless
Дата:
Сообщение: Re: weird GROUPING SETS and ORDER BY behaviour
Следующее
От: David Geier
Дата:
Сообщение: Re: postgres_fdw fails to see that array type belongs to extension