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
