Index-based Query Backend

[hraberg]

This new query backend will be based straight of the indexes and use worst case optimal joins.

These indexes are designed to be able to be semi-lazy, so only when sorting is necessary do they need to realise full results from an index (but usually not for the entire query). One goal is to be able to get a lazy seq of results, so one can handle much larger result sets.

The indexes have implicit support for normal unification joins and ranges, so these features will be kept from the current query capabilities.

Set based not, != should be possible to add. Clause-based not (ie. not-exists) should also be possible to implement. We also aim to support or. Support for and is implicit, but the operator might be needed for certain scenarios with nesting.

We don't aim to support or-join or not-join yet, as they are a bit quirkier both to understand and to implement.

Function predicates (other than the built-ins) can be added as a post-processing step when realising a single result, but often they should be possible to push down as an decorator on a specific unary index. Predicates operate on the ground facts, and need the entity documents to retrieve the attribute values.

This issue is closely related to #10.

[hraberg]

See https://developer.logicblox.com/content/docs4/core-reference/webhelp/formula.html for discussions and examples of disjunction (or) and negation.

[hraberg]

See also "6.2 Extension to ∃1 queries" in https://arxiv.org/pdf/1210.0481.pdf for discussion about disjunction, predicates and negation.

[hraberg]

I'm closing this as we support the basic cases now. Work has been done to prepare general nesting, but this isn't necessarily a priority for the MVP.