Re: CTE optimization fence on the todo list?

I need this feature a lot. Can anyone point me to a place in the code
where I can hack together a quick-and-dirty, compatibility-breaking
implementation? Thanks!

On Sun, May 3, 2015 at 10:03 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

> On 5/3/15 11:59 AM, Andrew Dunstan wrote:
>
>>
>> On 05/03/2015 11:49 AM, Tom Lane wrote:
>>
>>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>>
>>>> On 05/01/2015 07:24 PM, Josh Berkus wrote:
>>>>
>>>>> (A possible compromise position would be to offer a new GUC to
>>>>>> enable/disable the optimization globally; that would add only a
>>>>>> reasonably
>>>>>> small amount of control code, and people who were afraid of the change
>>>>>> breaking their apps would probably want a global disable anyway.)
>>>>>>
>>>>> This could be a very bad, almost impossible to catch, behaviour break.
>>>> Even if we add the GUC, we're probably going to be imposing very
>>>> significant code audit costs on some users.
>>>>
>>> On what grounds do you claim it'd be a behavior break? It's possible
>>> that the subquery flattening would result in less-desirable plans not
>>> more-desirable ones, but the results should still be correct.
>>>
>>
>> I meant w.r.t. performance. Sorry if that wasn't clear.
>>
>
> To put this in perspective... I've seen things like this take query
> runtime from minutes to multiple hours or worse; bad enough that "behavior
> break" becomes a valid description.
>
> We definitely need to highlight this in the release notes, and I think the
> GUC would be mandatory.
> --
> Jim Nasby, Data Architect, Blue Treble Consulting
> Data in Trouble? Get it in Treble! http://BlueTreble.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>