Misleading partition row count in Aggregation Design Wizard when measure group is at a higher level than its source granularity

Problem

I was recently analyzing a MDX query for its performance. I realized that the query was hitting more than one partition even though the query had a monthly slice specified and the measure group was partitioned by month using a date key. The Date key was a smart key and did not overlap between monthly partitions.

After further investigation, I found out that the respective partitions did not have any indexes built no matter how I processed them. This was true even after a full process. The estimated row counts and the dimension attribute counts were all specified. The partition row count was way over the minimum limit of 4096 rows. The source table had close to 3 million rows for each month.

 Misleading partition row count in Aggregation Design Wizard when measure group is at a higher level than its source granularity