Re: Assert failure in CTE inlining with view and correlated subquery
От | Tomas Vondra |
---|---|
Тема | Re: Assert failure in CTE inlining with view and correlated subquery |
Дата | |
Msg-id | d217eb59-835f-3844-8279-829fac9fd22d@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Assert failure in CTE inlining with view and correlated subquery (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Assert failure in CTE inlining with view and correlated subquery
|
Список | pgsql-hackers |
On 4/21/22 21:03, Tom Lane wrote: > Tomas Vondra <tomas.vondra@enterprisedb.com> writes: >> On 4/21/22 10:29, Richard Guo wrote: >>> 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? > > I think we should just drop this cross-check altogether; it is not nearly > useful enough to justify the work that'd be involved in maintaining > cterefcount accurately for all such transformations. All it's really > there for is to be sure that we don't need to make a subplan for the > inlined CTE. > > There are two downstream consumers of cte_plan_ids, which currently just > have Asserts that we made a subplan. I think it'd be worth converting > those to real run-time tests, which leads me to something more or less as > attached. > WFM. I'm not particularly attached to the assert, so if you say it's not worth it let's get rid of it. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: