This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
The DB2 optimizer continually reevaluates all conditions/variables to create the best plan at that moment. And almost always, the optimizer creates the best plan. There are times however, when the optimizer makes a poor choice. And when it does, the results can be dramatic (and disastrous) as there is no quick recovery... there is no easy way to force the optimizer to lock in on a plan that it has already created. We do see the REOPTIMIZE_ACCESS_PLAN(*ONLY_REQUIRED) property in QAQQINI, but this is difficult to scope for just a particular query/plan. If there was an ability to set this attribute to a particular plan/query from the Navigator UI, that would be ideal.
This is slightly different from the Optimizer Hints feature provided in other DB's (although that would be nice as well).
In this case, we simply(?) want the ability to lock in on a plan that the optimizer already created. This feature would/should be used very infrequently as the optimizer normally gets its right. But when he doesn't, it's lights out and a lot effort to fix. Either we have to tweak the application to give the optimizer something that is reliably evaluated, or we have to wait for an optimizer PTF. Both could be avoided by a 'lock in' feature.
Beyond avoidance of the optimizer suddenly/randomly choosing a poor plan/index, there is another benefit: avoiding excessive plan re-evaluation. In some cases, we have a set of queries/plans that are constantly (5x per second) being tossed and re-evaluated, thereby reducing our plan cache hit ratio. We've tried tweaking things (e.g. using the VOLATILE attribute) to influence the optimizer to let it alone. But we've not been successful.
Do not place IBM confidential, company confidential, or personal information into any field.