The Translation to an Execution Tree

The Translator unit will translate the Query Tree into an Execution Tree. All Domains have been intersected at this point and every PredicateTree node of the QT has an Intersection object attached to it.

The nodes may be translated in a straightforward fashion:

The translation  would be straightforward if we did not take any optimization into account. Effectively, in general we have   The following Scope Queries are generated from a Predicate Tree Leaf Node:

Aspects of Optimization

The Predicates involved in the Query Tree may be optimized in order to have an Execution Tree that executes faster. There are several factors that might influence the speed of a query. We already optimize for

  We may invent additional optimizations considering All these optimizations tend to produce more SQ leaves on the XT. The bounds for the size of the XT are set by considering   Intermediate bags There should be as few intermediate bags as possible, especially if they have a large content.   Memory Objectivity allocates for each thread a certain amount of memory when it initializes and it allocates a handle. There is an upper bound for the number of handles.   Load balancing The I/O channels associated with each partition should have the same amount of load to manage.


There is an object indicating the cost to retrieve objects from a Domain. This information is be calculated from the constructed Execution Tree and the Query Tree it was constructed from. The number of SQ leaves on the XT, the number of different partitions involved, the number of Databases/Containers to be opened are returned.