Module eligibility 

Eligibility analysis: decide whether a HypergraphRule can be planned as a multiway join, or must fall back to the existing binary-join lowering.

“Eligible” here means could be planned as multiway — it does NOT mean “must use multiway”. A rule with exactly two positive atoms is eligible because the planner could legally choose either a multiway plan or a binary plan; the choice is the planner’s, not the analyzer’s. The CPU reference evaluator (PR 2) and later GPU kernels (PR 3) consume both shapes.

“Ineligible” means at least one Boundary makes multiway planning either impossible (negation, aggregation in head) or unsupported by the executor context under consideration. Each boundary is reported separately so the explain output and tests can lock in why a rule fell back.

Enums

Boundary

One reason a rule is ineligible for multiway planning.

Eligibility

Verdict for a single rule.

ExecutorContext

Executor capability context for join-key width checks.

Constants

BINARY_FALLBACK_KEY_LIMIT

The maximum number of distinct join-key variables supported by the existing binary-fallback executor. Borrowed verbatim from the pack_keys_gpu_on_stream constraint in xlog-cuda/src/provider/relational.rs.

WCOJ_ELIGIBLE_KEY_LIMIT

The widest K-clique shape the WCOJ planner architecture admits at the eligibility layer. K=7 and K=8 are accepted here so the Phase-2 templates can inherit the same planner contract.

WCOJ_SUPPORTED_KEY_TYPES

Scalar types that the WCOJ reference evaluator supports as join-key types. Membership is checked by analyze_typed when emitting Boundary::UnsupportedKeyType.

Functions

analyze

Analyze a HypergraphRule and return the eligibility verdict.

analyze_typed

Typed eligibility analysis.

is_eligible

Return true when analyze says the rule is eligible in the selected executor context.