Re: Assert failure in CTE inlining with view and correlated subquery - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Assert failure in CTE inlining with view and correlated subquery
Date
Msg-id 48ee60e4-7ec3-ab21-ff67-e7f9dc2e37b1@enterprisedb.com
Whole thread Raw
In response to Re: Assert failure in CTE inlining with view and correlated subquery  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Assert failure in CTE inlining with view and correlated subquery  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 4/21/22 10:29, Richard Guo wrote:
> 
> On Thu, Apr 21, 2022 at 3:51 PM Richard Guo <guofenglinux@gmail.com
> <mailto:guofenglinux@gmail.com>> wrote:
> 
> 
>     On Thu, Apr 21, 2022 at 5:33 AM Tomas Vondra
>     <tomas.vondra@enterprisedb.com
>     <mailto:tomas.vondra@enterprisedb.com>> wrote:
> 
> 
>         it seems there's something wrong with CTE inlining when there's
>         a view
>         containing a correlated subquery referencing the CTE. 
> 
> 
>     BTW, seems view is not a necessary condition to reproduce this issue.
>     For instance:
> 
>     create table t (a int, b int);
> 
>     explain (costs off) select a from
>     (
>         with t_cte as (select a, b from t)
>         select
>             a,
>             (select b from t_cte where t_cte.a = t.a) AS t_sub
>         from t
>     ) sub;
> 
> 
> Further debugging shows that in this repro the reference to the CTE is
> removed when generating paths for the subquery 'sub', where we would try
> to remove subquery targetlist items that are not needed. So for the
> items we are to remove, maybe we need to check if they contain CTEs and
> if so decrease cterefcount of the CTEs correspondingly.
> 

Right, at some point we remove the unnecessary targetlist entries, but
that ignores the entry may reference a CTE. That's pretty much what I
meant by the counter being "out of sync".

Updating the counter while removing the entry is one option, but maybe
we could simply delay counting the CTE references until after that?


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Dump/Restore of non-default PKs
Next
From: Robert Haas
Date:
Subject: Re: Re: fix cost subqueryscan wrong parallel cost