pub struct CostModel { /* private fields */ }Expand description
Cost model for estimating operator costs.
Implementations§
Source§impl CostModel
impl CostModel
Sourcepub fn estimate(&self, op: &LogicalOperator, cardinality: f64) -> Cost
pub fn estimate(&self, op: &LogicalOperator, cardinality: f64) -> Cost
Estimates the cost of a logical operator.
Sourcepub fn cheaper<'a>(&self, a: &'a Cost, b: &'a Cost) -> &'a Cost
pub fn cheaper<'a>(&self, a: &'a Cost, b: &'a Cost) -> &'a Cost
Compares two costs and returns the cheaper one.
Sourcepub fn leapfrog_join_cost(
&self,
num_relations: usize,
cardinalities: &[f64],
output_cardinality: f64,
) -> Cost
pub fn leapfrog_join_cost( &self, num_relations: usize, cardinalities: &[f64], output_cardinality: f64, ) -> Cost
Estimates the cost of a worst-case optimal join (WCOJ/leapfrog join).
WCOJ is optimal for cyclic patterns like triangles. Traditional binary hash joins are O(N²) for triangles; WCOJ achieves O(N^1.5) by processing all relations simultaneously using sorted iterators.
§Arguments
num_relations- Number of relations participating in the joincardinalities- Cardinality of each input relationoutput_cardinality- Expected output cardinality
§Cost Model
- Materialization: O(sum of cardinalities) to build trie indexes
- Intersection: O(output * log(min_cardinality)) for leapfrog seek operations
- Memory: Trie storage for all inputs
Sourcepub fn prefer_leapfrog_join(
&self,
num_relations: usize,
cardinalities: &[f64],
output_cardinality: f64,
) -> bool
pub fn prefer_leapfrog_join( &self, num_relations: usize, cardinalities: &[f64], output_cardinality: f64, ) -> bool
Compares hash join cost vs leapfrog join cost for a cyclic pattern.
Returns true if leapfrog (WCOJ) is estimated to be cheaper.
Sourcepub fn factorized_benefit(&self, avg_fanout: f64, num_hops: usize) -> f64
pub fn factorized_benefit(&self, avg_fanout: f64, num_hops: usize) -> f64
Estimates cost for factorized execution (compressed intermediate results).
Factorized execution avoids materializing full cross products by keeping results in a compressed “factorized” form. This is beneficial for multi-hop traversals where intermediate results can explode.
Returns the reduction factor (1.0 = no benefit, lower = more compression).