SELECT CUBE_NAME
, DIMENSION_CAPTION AS TableName
, DIMENSION_CARDINALITY AS RowCount
FROM $system.MDSchema_Dimensions
ORDER BY DIMENSION_CARDINALITY DESC

AMO libraries

  3.  Update the refreshType parameter according to how you would like to process the tables. The options are documented here.

Let's say I have a file, myfile.txt, with the following content:

I was presented with this very situation where a distinct count over an 18 billion row table was the denominator for most calculations and performance was terrible. They wanted dashboards to render in under 10 seconds even when looking at sales change year-over-year for the entire company. This blog post summarizes the approach we took to optimize their Analysis Services Tabular model distinct counts to meet those performance expectations.

We’ll tie the individual build steps together via PowerShell.

So, with 32 cores to play with, we should be looking at the default segment size (8m) or maybe reduce it to 4m to get 40 segments. But the extra compression with 16m segment size may be of benefit. So I ran some timing tests on the distinct count measure, and the results are quite interesting.

Every table in Tabular has one or more partitions.Every partition defines a set of rows that are read from the source table. Every partition can be processed independently and in parallel with others, so you can use partitions to accelerate the processing of a single table.You define partitions related to the source table, but from the Tabular point of view, every table is made of several columns, and every column is a different object. Some columns are calculated and based on the data of other columns belonging to the same or different tables. The engine knows the dependencies of each calculated column and calculated table. When you process a partition of a table, every dependent calculated table must be completely recalculated. Moreover, every calculated column in the same or other tables must be completely recalculated for the entire table to which it belongs.