Skip to main content

Pentaho+ documentation has moved!

The new product documentation portal is here. Check it out now at


Hitachi Vantara Lumada and Pentaho Documentation

Configure Mondrian engine

The Pentaho Mondrian engine is configurable through a properties file. Mondrian options allow for enhanced engine and data source performance and functionality under certain conditions. Pentaho Analyzer is also configurable, but more in terms of adjusting the functionality of the Analyzer client tool itself.

Manage Analyzer data sources

In order to use a properly prepared data source with Pentaho Analyzer, it must be established in either the User Console as a Native (JDBC) data source, or in your Web application server as a JNDI data source.

Whichever method you choose, you will have to know the name of the data source later on when you are asked to supply it in Pentaho Schema Workbench.

NoteSchema Workbench can only work with one data source for each Mondrian schema; this is a structural limitation in the software that will be remedied at a later time. You can have multiple JNDI or Native (JDBC) data sources established, but only one at a time can be used with Schema Workbench.

Edit the Mondrian Properties File

The file located in the pentaho/server/pentaho-server/pentaho-solutions/system/mondrian folder. Edit this file to adjust the Mondrian engine for performance and usability within our specific environment.

NoteThis section is specific to maximizing Mondrian performance with Pentaho Analyzer. For all available settings, see


One of the key performance goals for Analyzer is to push as many operations to the database as possible. This is particularly important when querying many high-cardinality dimensions because you want Mondrian to only process the combinations that make sense and not a huge cartesian product which is sparsely populated.

Pay particular attention to the following engine properties:


Improves the performance of summary numbers such as ranks and running sums.


This is an essential property which enables pushdown to the database so that Mondrian does not perform large cross joins in memory.


Particularly important for pushdown of Not In and Excludes filters.


This should be set to false to optimize Mondrian SQL generation given the MDX patterns generated by Analyzer. Analyzer uses non-empty cross joins to push down joins between high cardinality attributes to the database. If this property is set to false, there are many non-empty cross joins which would get evaluated by Mondrian instead because Mondrian pushes down the individual arguments such as dimension.members.


Used in conjunction with the mondrian.native.ExpandNonNative property. This should be set to as large as the underlying database can support.


Allows pushdown of even more cross joins by materializing the cross join inputs into IN lists. For example, a cross join whose inputs are MDX functions can first have their inputs evaluated to members and then convert the cross join into native evaluation.


Analyzer always generates dimension qualified members so no need to spend time searching for members on different dimensions.

Mondrian Usability Properties

You can set certain properties to improve usability. Pay particular attention to the following engine properties:


In the event that pushdown cannot occur, this is the largest cross join size that Mondrian should try to process. Anything that exceeds this will likely send the CPU for a toss and result in long server hangs. If this limit is hit, Analyzer will present the user a nice warning suggesting options to simplify the report.

This is important for Equals filters because the UI will preserve the casing of filter values. If the user defines a filter on John Doe, then the filter should only apply to "John Doe" and not "john doe".


This is important for saved reports because the user may build a report with a filter on 10 sales rep and after the next ETL, one of them is gone. The report should continue to run and return just the 9 remaining sales reps.


See mondrian.olap.ignoreInvalidMembers


Similar to mondrian.result.limit except for controlling limits on aggregate evaluation.


This is required for sorting members in a dimension A->Z or Z->A. This property fixes a bug in Mondrian but was added for backward compatibility.


The best way to understand this property is via an example. Suppose you want to see quota attainment for your sales reps which is computed as Booked Deals / Quota. Some reps may not have quotas and so quota attainment is either infinity or null. By treating "divide by null" as infinity, Mondrian will return these sales reps in the report. Otherwise, if "divide by null" equates to null, then Mondrian will filter those reps out (due to the NON EMPTY).