Sv: Re: Sv: Re: CTE optimization fence - Mailing list pgsql-general

From Andreas Joseph Krogh
Subject Sv: Re: Sv: Re: CTE optimization fence
Date
Msg-id VisenaEmail.24.aff6251fef9d9dce.16440a8439b@tc7-visena
Whole thread Raw
In response to Re: Sv: Re: CTE optimization fence  (Adrien NAYRAT <adrien.nayrat@anayrat.info>)
Responses Re: Sv: Re: Sv: Re: CTE optimization fence  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-general
På onsdag 27. juni 2018 kl. 11:44:05, skrev Adrien NAYRAT <adrien.nayrat@anayrat.info>:
On 06/27/2018 09:58 AM, Andreas Joseph Krogh wrote:
>      >
>      > 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
>
> +1 from me. The default should be "no fence" for sake of least surprise
> I think. Documenting the change would be sufficient.
> I hope this will be picked up in the comming V12-cycle.


FYI this subject has been discussed in this thread :
https://www.postgresql.org/message-id/5351711493487900%40web53g.yandex.ru

Regards,
 
 
I know. I hate the INLINE proposal and hope default-behaviour will be like in other DBs, inline like sub-query as default. GUC for preserving fence is what I hope will happen.
 
--
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
 
Attachment

pgsql-general by date:

Previous
From: Adrien NAYRAT
Date:
Subject: Re: Sv: Re: CTE optimization fence
Next
From: Raymond O'Donnell
Date:
Subject: Re: Code of Conduct committee: call for volunteers