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
|
| Список | 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
relation, and it seems that there is no other way to reference such a
Var other than using CTE.
Thanks
Richard
В списке pgsql-hackers по дате отправления: