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
tofind 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
havedoubts about that precept but without _some_ change in attack CTEs approach fluff.
> On Jun 26, 2018, at 11:45 PM, Thomas Kellerer <spam_eater@gmx.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
>
