Sv: Re: CTE optimization fence

From: Andreas Joseph Krogh <andreas(at)visena(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Sv: Re: CTE optimization fence
Date: 2018-06-27 07:58:21
Message-ID: VisenaEmail.19.aa49bd9c1e9ea86.164403ee18c@tc7-visena
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

På onsdag 27. juni 2018 kl. 07:45:25, skrev Thomas Kellerer <spam_eater(at)gmx(dot)net
<mailto:spam_eater(at)gmx(dot)net>>:
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
 
+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.
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andreas(at)visena(dot)com <mailto:andreas(at)visena(dot)com>
www.visena.com <https://www.visena.com>
<https://www.visena.com>

 

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Akshaya Acharya 2018-06-27 09:29:29 Re: Too many range table entries error
Previous Message Laurenz Albe 2018-06-27 07:19:05 Re: About "Cost-based Vacuum Delay"