Skip to main content
A query follows several steps before a result is returned. Each step affects performance. Understanding how these steps fit together helps identify where slowdowns occur and which optimizations to apply. Prerequisites: Familiarity with measures, cube structure, and datastore loading is recommended before reading this section.

​
How are queries executed by Atoti?

The primary query type in Atoti is the MDX query. When Atoti receives an MDX query, it parses the query and breaks it down into Get Aggregates Queries (GAQs). Each GAQ requests one or more measures at a given set of locations. For each GAQ, Atoti computes a query plan that defines how the requested measures will be retrieved or calculated.

​
How are values retrieved?

The fastest method is to take the values from the aggregate cache. When this is not possible, the values are computed.

​
Aggregate Cache

The fastest option is to retrieve the measure value directly from the Aggregate Cache. This cache stores location-measure combinations that were already computed by a previous query. If the requested combination is present in the cache, Atoti returns the result immediately without any further computation.

​
How are measures computed?

If the value is not cached, Atoti computes the measure at the requested locations. Most measures are computed from other, simpler child measures. The calculation breaks down until it reaches the simplest possible measures, called primitive measures. These are defined as basic aggregations over the fact table. Primitive measures are resolved through one of the following:
  • Aggregate Providers: Aggregate Providers are materialized views that store pre-computed primitive measure values at a defined granularity. The Aggregate Cache holds recently used location-measure combinations on demand. Aggregate Providers differ: they are updated every time a data load is triggered. An Aggregate Provider can resolve a location-measure combination when the requested location matches its granularity. It can also resolve locations at a coarser granularity than the provider. In the latter case, the query engine aggregates the relevant rows from the Aggregate Provider to produce the result.
  • Database
    • Datastore: if no Aggregate Provider can resolve the combination, the engine falls back to the Datastore. The Datastore engine collects all fact records matching the requested location and aggregates them to produce the result.
    • DirectQuery: when using an external database, the connector generates a SQL query. This query computes the aggregation directly from the external data source.
Once all necessary primitive aggregations are available, Atoti computes each measure in order. This continues until all requested measures have been resolved. perf-query-journey.png

​
How is the MDX query result assembled?

When all GAQs for an MDX query have been computed, the MDX query engine applies any MDX-level computations. It then assembles the final result as a Cellset. The Cellset is returned to the caller.

​
What is the query plan?

A significant portion of MDX query execution is captured by the query plan. After a query executes, the query plan provides a detailed record of every step taken. This record includes calculation order, execution times, result sizes, and retrieval methods. When a query performs slower than expected, the query plan is the primary diagnostic tool. It identifies which step is responsible.

​
What are query limits?

Users can define limits to enforce time and size constraints on the query execution process.