Repository navigation
feat: make max_derived_facts_per_iteration configurable (currently hard-coded at 100,000) #288
Description
Problem
The RecursiveEvaluator and StratifiedEvaluator hard-code DEFAULT_MAX_DERIVED_FACTS = 100_000 facts per iteration. On a real-world repository with ~1,000 commits, a transitive-closure rule like ancestor hits this limit immediately:
msg='Max derived facts per iteration (100000) exceeded. Rule may be generating too many facts.'
A 986-commit linear-ish git history can easily produce >100,000 ancestor pairs across the full transitive closure. The bottom-up semi-naive evaluator computes the complete O(N²) closure before any query-level filtering, so even simple queries like "which tags contain this commit?" blow the limit.
Suggested fix
- Raise the default — for the embedded use-case N² over 1,000 nodes is ~1M facts, still manageable in memory. A default of 1,000,000 or 10,000,000 would cover typical embedded workloads.
- Make it configurable via
OpenOptionsalongside the existingpage_cache_size:
pub struct OpenOptions {
pub page_cache_size: usize,
pub max_derived_facts_per_iteration: usize, // new
pub max_query_results: usize, // new
}- Long-term: demand-driven (top-down) evaluation or magic sets rewriting would avoid computing the full closure when only a subset is needed — but that's a larger change.
References
src/query/datalog/evaluator.rs—DEFAULT_MAX_DERIVED_FACTS,DEFAULT_MAX_RESULTSsrc/query/datalog/executor.rs—execute_query_with_rulespassesself.max_derived_facts
Activity
feat(mcp): add ancestor rule to SESSION_RULES for commit graph traver…
docs: add per-query complexity limits design spec (#288)
docs: add grammar.pest + wiki files to per-query limits spec (#288)
feat(query): per-query :max-derived-facts and :max-results; raise def…