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!
(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
