Re: CTE optimization fence
От
Thomas Kellerer
Тема
Re: CTE optimization fence
Дата
Msg-id
d37c4340-ff95-ffe6-02e7-f4adf0352761@gmx.net
Ответ на
Re: CTE optimization fence (Tom Lane)
Список
Дерево обсуждения
CTE optimization fence Guy Burgess <guy@burgess.co.nz>
Re: CTE optimization fence Tom Lane <tgl@sss.pgh.pa.us>
Re: CTE optimization fence Thomas Kellerer <spam_eater@gmx.net>
Re: CTE optimization fence Rob Sargent <robjsargent@gmail.com>
Sv: Re: CTE optimization fence Andreas Joseph Krogh <andreas@visena.com>
Re: Sv: Re: CTE optimization fence Adrien NAYRAT <adrien.nayrat@anayrat.info>
Sv: Re: Sv: Re: CTE optimization fence Andreas Joseph Krogh <andreas@visena.com>
Re: Sv: Re: Sv: Re: CTE optimization fence Alvaro Herrera <alvherre@2ndquadrant.com>
Tom Lane schrieb am 27.06.2018 um 05:48: >> I see there was some discussion last year about removing the CTE >> optimization fence (e.g. >> http://www.postgresql-archive.org/CTE-inlining-td5958992.html) but can't >> find anything more recent. Does anyone know if this is still under >> consideration? > > but we have to settle on a way of controlling it. +1 from me. I am running more and more into situations where people consider this a bug rather than a feature. FWIW, I think a GUC that switches between the current (mostly unwanted, at least surprising) way and one where the CTE is optimized together with the main query would suit "most" people. For sake of compatibility this could default to the current behaviour
В списке pgsql-general по дате отправления