| From: | Adrien NAYRAT <adrien(dot)nayrat(at)anayrat(dot)info> |
|---|---|
| To: | Andreas Joseph Krogh <andreas(at)visena(dot)com>, <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Sv: Re: CTE optimization fence |
| Date: | 2018-06-27 09:44:05 |
| Message-ID: | bd64092d-ad4a-9b74-f2f8-ed750347a3dd@anayrat.info |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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,
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andreas Joseph Krogh | 2018-06-27 09:54:33 | Sv: Re: Sv: Re: CTE optimization fence |
| Previous Message | ERR ORR | 2018-06-27 09:44:02 | Re: Code of Conduct committee: call for volunteers |