Re: CTE optimization fence

I don’t think the fence analogy works. Try wall (a la Berlin).
I count myself amongst those who thought “Ooh this little CTE will garner just what the rest of the query needs”. Only to find the planner didn’t groc that optimization.

Is it a matter of deciding to trust the SQLer and runtime analyzing the CTE product before continuing? As an SQLer I have doubts about that precept but without _some_ change in attack CTEs approach fluff.

> On Jun 26, 2018, at 11:45 PM, Thomas Kellerer <spam_eater(at)gmx(dot)net> wrote:
>
> 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
>