Replied 3 August 2017, 3:50 pm EST
Thank you for your patience while I've looked into this. After remodeling my test database to more closely match your schema, I was able to reproduce similar slow performance. I have addressed this to our development staff as case 117845 and included your email address with the list of affected users for the case. If you would like to be notified when a new build is made available that addresses this issue, you can subscribe to the announcements forums here: http://www.datadynamics.com/forums/81/ShowForum.aspx
Based on the schema you provided, I have noticed a couple of things that might help to improve the performance. For starters I would recommend moving the measures that are related to dates from the measures dimension to an attributes dimension. However, please note that if the date fields are the result of using the MySql date functions within your query string you could move the date fields by simply regenerating the schema without using these functions as the Schema AutoGenerator will automatically generate a date dimension with date attributes and a hierarchy for each date field. If this is not the case and each field is stored in the database separately, you can move the fields from the measures dimension to the attributes dimension (or a new attribute dimension) by either using the schema builder API or by directly modifying the XML of the Schema file in a text editor so that the items pertaining to the date fields in the measures dimension are moved to the attributes dimension. Another potential problem I have noticed is the "Description" field. If this field contains detailed descriptions of each item (i.e. one sentence to multiple paragraph descriptions), I would recommend removing this field from the schema altogether as this may greatly reduce the amount of data loaded into the internal data manager and in turn may reduce the loading time.
If you have any additional questions please feel free to let me know.