99 lines
2.0 KiB
Markdown
99 lines
2.0 KiB
Markdown
|
# Rule Engines and Fixpoint Evaluation
|
||
|
|
|
||
|
|
A reference for query engines whose core work is inference, recursion, or repeated rule application.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Short answer
|
||
|
|
|
||
|
|
Not all query engines are centered on SQL-style scans, joins, and aggregates.
|
||
|
|
|
||
|
|
Some are organized around:
|
||
|
|
|
||
|
|
- facts
|
||
|
|
- rules
|
||
|
|
- recursion
|
||
|
|
- derivation until no new information appears
|
||
|
|
|
||
|
|
That is the world of rule engines, Datalog engines, and chase-style systems.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## The core idea
|
||
|
|
|
||
|
|
Instead of asking only for direct data retrieval, a rule engine often asks:
|
||
|
|
|
||
|
|
- what facts follow from these rules?
|
||
|
|
- what closure or least fixpoint do these inputs imply?
|
||
|
|
- what new values must exist to satisfy constraints?
|
||
|
|
|
||
|
|
This makes the engine iterative in a deeper way than many classical relational plans.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Fixpoint evaluation
|
||
|
|
|
||
|
|
Fixpoint evaluation means:
|
||
|
|
|
||
|
|
1. start with known facts
|
||
|
|
2. apply rules
|
||
|
|
3. add newly derived facts
|
||
|
|
4. repeat until nothing new is produced
|
||
|
|
|
||
|
|
That final stable state is the fixpoint.
|
||
|
|
|
||
|
|
This is central to:
|
||
|
|
|
||
|
|
- recursive Datalog
|
||
|
|
- transitive closure
|
||
|
|
- many inference systems
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## How this differs from standard relational execution
|
||
|
|
|
||
|
|
Relational engines often execute one finite plan over a fixed input.
|
||
|
|
|
||
|
|
Rule engines often need:
|
||
|
|
|
||
|
|
- iterative scheduling
|
||
|
|
- duplicate elimination
|
||
|
|
- dependency tracking
|
||
|
|
- recursion support
|
||
|
|
- possibly witness generation or equality merging
|
||
|
|
|
||
|
|
So the runtime model is often different even when some individual operators overlap.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Why this matters
|
||
|
|
|
||
|
|
Rule/fixpoint execution is especially relevant when the system needs:
|
||
|
|
|
||
|
|
- recursive reasoning
|
||
|
|
- closure computation
|
||
|
|
- derivation of implicit facts
|
||
|
|
- chase-like enforcement of dependencies
|
||
|
|
|
||
|
|
This makes it a natural topic whenever query engines overlap with logic or theorem-like data processing.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Practical mental model
|
||
|
|
|
||
|
|
Standard query engines answer:
|
||
|
|
|
||
|
|
- what result follows from this query over this data?
|
||
|
|
|
||
|
|
Rule engines also ask:
|
||
|
|
|
||
|
|
- what additional facts become true once the rules have run to completion?
|
||
|
|
|
||
|
|
That is the essential distinction.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Changelog
|
||
|
|
|
||
|
|
* **April 1, 2026** -- First version created.
|