Struct JoinOrderSearch 

pub struct JoinOrderSearch { /* private fields */ }

Performs join order optimization via exhaustive search

Implementations

impl JoinOrderSearch

pub fn from_analyzer(analyzer: &JoinOrderAnalyzer, database: &Database) -> Self

Create a new join order search from an analyzer with real table statistics

pub fn from_analyzer_with_predicates( analyzer: &JoinOrderAnalyzer, database: &Database, table_local_predicates: &HashMap<String, Vec<Expression>>, alias_to_table: &HashMap<String, String>, ) -> Self

Create a new join order search with WHERE clause selectivity applied

This version accounts for table-local predicates when estimating cardinalities, which helps choose better join orders for queries like TPC-H Q3 where filter predicates significantly reduce table sizes before joining.

Parameters

• alias_to_table: Maps table aliases (e.g., “n1”, “n2”) to actual table names (e.g., “nation”). This is critical for queries with self-joins (like TPC-H Q7 with two nation aliases) to correctly look up table cardinalities and statistics.

pub fn from_analyzer_with_aggregates( analyzer: &JoinOrderAnalyzer, database: &Database, table_local_predicates: &HashMap<String, Vec<Expression>>, alias_to_table: &HashMap<String, String>, aggregate_analysis: AggregateAnalysis, ) -> Self

Create a new join order search with aggregate-aware optimization

This version accepts aggregate analysis results and can adjust join order decisions based on GROUP BY/HAVING clauses. When HAVING filters are selective, the optimizer may prefer different join orders that enable early aggregation.

Parameters

• alias_to_table: Maps table aliases to actual table names for database lookups.

pub fn find_optimal_order(&self) -> Vec<String>

Find optimal join order by exploring search space

Returns list of table names in the order they should be joined.

When time-bounded search is enabled (default), uses parallel BFS for all multi-table queries with a configurable time budget. This allows optimization of large queries (9+ tables) while preventing excessive search time.

When time-bounded search is disabled, uses legacy behavior: parallel BFS for 3-6 table queries with highly connected join graphs, DFS for others.