On the face of it, this seems pretty basic but I think I am getting thrown off by the finer details of SSAS query optimization. The query below runs pretty fast as it stands.
WITH DYNAMIC SET [Set BSE] as SsasStoredProcs.GetBranchReportingGroupSet('BSE')
MEMBER [Measures].[MySales1] as SUM(SsasStoredProcs.GetBranchReportingGroupSet('BSE') ,[Measures].[Sales])
MEMBER [Measures].[MySales2] as SUM([Set BSE] ,[Measures].[Sales])
SELECT [Measures].[MySales2] ON COLUMNS,
NON EMPTY [Customer].[Customer Code and Name].[Code] ON ROWS
FROM [Sales Budget and Activity]
The "SsasStoredProcs" CLR procedure retrieves a set of members on another dimension (Branch).
As I said, this query is fast. But when I replace MySales2 with MySales1 in the columns, my query runs extremely slowly. I think I'm moving back and forth from cell-by-cell computation to subspace computation mode. (Although the MSDN article says that I should be subjected to cell-by-cell in both cases - because of either the named set *or* because of the CLR procedure - take your pick).
Using SQL profiler tracing I am able to see that the use of MySales1 causes my stored procedure to execute for every single customer code. This is not the case with MySales2.
Can someone confirm my theory about the computation mode? How do I know for sure? Why can't MySales1 be fast too?
Ultimately I'd like to understand what is going on here. I have a goal to create a utility dimension that will calculate sums based on arbitrary named sets and I am a long way from accomplishing this.
Thanks, David