Example:
Measure: User Count (UserKey)
Partition 1, SQL Query Where Clause: WHERE UserKey BETWEEN -1 and 10
Partition 2, SQL Query Where Clause: WHERE UserKey BETWEEN 11 and 20
Partition 3, SQL Query Where Clause: WHERE UserKey BETWEEN 21 and 30
Partition 4, SQL Query Where Clause: WHERE UserKey BETWEEN 31 and 100
As recommended in distinct count optimization papers and other sources, we split the key which is being used to count across the partitions and achieve excellent performance on reads. My understanding is Analysis Services checks the header file which
contains the key ranges to determine which partitions to query.
Now the problem. We want to create new partitions with different where statements and merge into a blank partitions to help optimize processing.
Below are the steps:
1) Add 2 special partitions which will be processed and merged
Partition 5, SQL Query Where Clause: WHERE UserKey BETWEEN 101 and 1000 and Date BETWEEN '1/1/2013' and '1/31/2013'
Partition 6, SQL Query Where Clause: WHERE UserKey BETWEEN 101 and 1000 and Date BETWEEN '2/1/2013' and '2/28/2013'
2) Add an empty partition
Partition 7, SQL Query Where Clause: WHERE UserKey BETWEEN 101 and 1000
3) Merge Partition 5 and Partition 6 into Partition 7
Final result
Partition 1, SQL Query Where Clause: WHERE UserKey BETWEEN -1 and 10
Partition 2, SQL Query Where Clause: WHERE UserKey BETWEEN 11 and 20
Partition 3, SQL Query Where Clause: WHERE UserKey BETWEEN 21 and 30
Partition 4, SQL Query Where Clause: WHERE UserKey BETWEEN 31 and 100
Partition 7,
SQL Query Where Clause: WHERE UserKey BETWEEN 101 and 1000
Question: Does the Analysis Services engine have updated header following the merge which provides the same distinct count optimizations? Are there any other performance considerations when merging partitions which include distinct count measures?
Thanks in advance for any info