Currently, as I write a SELECT query with a correlated Sub-select (and no other predicates), I see that the optimization for that query uses a non-correlated sub-select and the query runs very fast. But, if I use exactly the same predicate, but write the query as an UPDATE, the optimizer does not enhance the query performance in the same manner that was done for the equivalent SELECT query. So, I have to re-write the query myself. I would like to have the fast performance (logic) that was applied to the SELECT call to also be applied to the UPDATE call.
|Who would benefit from this IDEA?||Developers and DBAs attempting to get better performance|
How should it work?
It should work in almost the same way that it works with a SELECT call.
|Customer Name||Mutual of Omaha|
NOTICE TO EU RESIDENTS: per EU Data Protection Policy, if you wish to remove your personal information from the IBM ideas portal, please login to the ideas portal using your previously registered information then change your email to "email@example.com" and first name to "anonymous" and last name to "anonymous". This will ensure that IBM will not send any emails to you about all idea submissions