Oliver Kennedy#DBToaster's Aggregate Calculus has a feature that I never paid much attention to before: It has well-defined evaluation logic for not only classical bottom-up ('compute a relation from the inputs') query evaluation, but also a more provenance-y top-down ('compute the value of a specific tuple') semantics. The latter is faster, as it avoids collection operations... but requires first computing the query's support. However, in some cases, the support is bounded and known at compile time...
This works even if only a projection of the support is known statically. While you don't get the speedup of avoiding collection operations outright, you do end up with this unusual monadic index-nested-loop-join evaluation strategy that manages to avoid pipeline blockers until the end of the query! I'm not convinced this is always a win (e.g., if your relations aren't indexed properly, or an aggregate substantially reduces cardinality), but the flexibility feels like it could be very powerful.