Subject | Using PLAN string in a view |
---|---|
Author | patrick_marten |
Post date | 2012-11-09T09:48:36Z |
Hello,
some time ago I've posted in the IBO support group (although it would have fit in here better) a question about custom PLAN strings for dynamic SQL statements of a query and the conclusion was, that there is mostly no need to use own PLAN strings, because the engine does it quite well.
Based on the replies in the other post I assume that the conclusion applies to views I'm creating as well, doesn't it? Although their statements are static, unlike the query in the question above, the PLAN string generated by the engine will probably be better here as well.
I have some views, which were created with a custom PLAN string. In order to be able to do some changes I had to drop some contraints temporary, but for one of them it failed, because there was 1 dependency. I checked the views and one was using that constraint in the custom PLAN string, so I would need to drop the view as well...
If I create the views without cutsom PLAN strings, could it still come to the same error, if the engine generates it's own PLAN string? I think no, because it would be generated only when accessing that view, but I'm not sure about it and wanted to ask for confirmation.
Best regards,
Patrick
some time ago I've posted in the IBO support group (although it would have fit in here better) a question about custom PLAN strings for dynamic SQL statements of a query and the conclusion was, that there is mostly no need to use own PLAN strings, because the engine does it quite well.
Based on the replies in the other post I assume that the conclusion applies to views I'm creating as well, doesn't it? Although their statements are static, unlike the query in the question above, the PLAN string generated by the engine will probably be better here as well.
I have some views, which were created with a custom PLAN string. In order to be able to do some changes I had to drop some contraints temporary, but for one of them it failed, because there was 1 dependency. I checked the views and one was using that constraint in the custom PLAN string, so I would need to drop the view as well...
If I create the views without cutsom PLAN strings, could it still come to the same error, if the engine generates it's own PLAN string? I think no, because it would be generated only when accessing that view, but I'm not sure about it and wanted to ask for confirmation.
Best regards,
Patrick