Re: Early WIP/PoC for inlining CTEs
От | Tom Lane |
---|---|
Тема | Re: Early WIP/PoC for inlining CTEs |
Дата | |
Msg-id | 10371.1542410691@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Early WIP/PoC for inlining CTEs (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Список | pgsql-hackers |
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: > Tom> * I have no faith in the idea that we can skip doing a copyObject > Tom> on the inlined subquery, except maybe in the case where we know > Tom> there's exactly one reference. > The code doesn't do a copyObject on the query if there are no level > changes because everywhere else just does another copyObject on it as > the first processing step (cf. set_subquery_pathlist and the various > functions called from pull_up_subqueries). Perhaps it's safe today, but is that likely to remain true? We've had enough pain in the past from multiply-linked parse subtrees that I am not eager to introduce another case, especially not here where there's absolutely no evidence that it'd provide a meaningful performance improvement. > Tom> * Speaking of the comments, I'm not convinced that view rewrite is > Tom> a good comparison point; I think this is more like subquery > Tom> pullup. > It's not really like subquery pullup because we actually do go on to do > subquery pullup _after_ inlining CTEs. Subquery pullup can happen across multiple levels, too. regards, tom lane
В списке pgsql-hackers по дате отправления: