Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500 - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500
Date
Msg-id CAMbWs49cnL7OcSfiyJ_VEKSYE1L5X7KjhOtVzSmkSauE89pLPQ@mail.gmail.com
Whole thread Raw
In response to Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500
List 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 by date:

Previous
From: Geoff Winkless
Date:
Subject: Re: weird GROUPING SETS and ORDER BY behaviour
Next
From: David Geier
Date:
Subject: Re: postgres_fdw fails to see that array type belongs to extension