Consider the following expression:
set{1..100} intersection set{200..10000}
If a human can evaluate this expression to the empty set without materializing 100+(10000-200)=>9900 values, then a DBMS should as well: the above intersection could correspond very obviously to a join condition.
Symbolic evaluation is not merely a static optimization, however. For example, if we have a set of materialized tuples and corresponding b+tree, the set of updates could be used to construct a b+tree filter to execute the join.
Project:M36 is in a unique position to take advantage of such optimizations because it stores the state update expressions and a full database state history. This ticket is a placeholder to remind me to explore this kind of optimization by laying out its coverage, mathematics, and limitations.
Consider the following expression:
set{1..100} intersection set{200..10000}If a human can evaluate this expression to the empty set without materializing 100+(10000-200)=>9900 values, then a DBMS should as well: the above intersection could correspond very obviously to a join condition.
Symbolic evaluation is not merely a static optimization, however. For example, if we have a set of materialized tuples and corresponding b+tree, the set of updates could be used to construct a b+tree filter to execute the join.
Project:M36 is in a unique position to take advantage of such optimizations because it stores the state update expressions and a full database state history. This ticket is a placeholder to remind me to explore this kind of optimization by laying out its coverage, mathematics, and limitations.