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.na...@bluetreble.com> wrote: > On 5/3/15 11:59 AM, Andrew Dunstan wrote: > >> >> On 05/03/2015 11:49 AM, Tom Lane wrote: >> >>> Andrew Dunstan <and...@dunslane.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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
