Hi folks,
We have an SQL type calculation view that is performing badly. Upon analyzing the visual plan we have found the root of the problem due to a case statement that is simply evaluating two tables and if a field is null in one table then choose the other alternate table field; something like this;
select
case when a.Customer IS NULL THEN
b.Customer
else
a.Customer
End
As TheCustomer
from table1 a join table2 b on a.XYZ = b.XYZ
etc
If we take the case statement away and simply return both values, the query runs very fast around 2 seconds. ie: something like this;
select
a.Customer as Customer1,
b.Customer as Customer2
from table1 a join table2 b on a.XYZ = b.XYZ
etc
But doing the case evaluation between the two field values bumps the execution time up to more than 60 seconds!
Has anybody experienced this and do you have any alternative suggestions to achieve this sort of thing? We have also tried doing a second pass and putting the case evaluation OUTSIDE the original select statement and there is some big improvement yet still not satisfactory. ie: something like this;
select
case when a.Customer IS NULL THEN
b.Customer
else
a.Customer
End
As TheCustomer from
( select
a.Customer as Customer1,
b.Customer as Customer2
from table1 a join table2 b on a.XYZ = b.XYZ
etc)
Thanks,
-Patrick
Request clarification before answering.
Hi guys,
After reading your suggestion we tried coalesce however we did not see any improvement whatsoever. Also thanks for the tips Lars. What we did find was that if we used input parameters the performance was greatly improved. Strangely the original case statement OR the coalesce both performed well when we restarted our server (we have seen strange issues with 68 like this) but only when running the entire raw SQL script inside SQL editor. ie: if our calculation view contains 100 lines of code and we paste it into SQL editor it works great. Alternatively if we reference the view directly like this;
select * from "SYS_BIC"."CalcViewName" where condition = 'abc'
This performance is bad. If we parameterize the calculation view and change the way we reference the view like this it is now flying;
select * from "SYS_BIC"."CalcViewName"
('PLACEHOLDER' = ('$$CONDITION$$', ''abc'''))
This makes sense to me as it seems to be pushing the filter to the beginning of the query. What does not make sense to us is why running the entire SQL directly in SQL editor (without parameters) works very fast as well. It's only when calling the view directly via SYS_BIC that it becomes slow and then requires the input parameters. You might then ask why we care, just put the input parameters in the view and call it done! Well the issue is with Microstrategy tool that we are using which has limitation around multiple values in a single parameter.
-Patrick
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.