Join DAG Construction for Query Optimization

• Join DAG construction is a method that builds a directed acyclic graph representing all intermediate join results for systematic query optimization.
• It employs both full enumeration and incremental updating techniques to efficiently manage complex multi-join queries.
• Cost models based on cardinality and selectivity are integral, enabling early selection placement that refines join plans and minimizes intermediate result sizes.

A join Directed Acyclic Graph (join DAG) is a foundational data structure in the representation and optimization of relational database queries involving join operations. Each node in a join DAG corresponds to an intermediate join result over a subset of base relations, and directed edges represent individual join operations. The construction, maintenance, and utilization of join DAGs directly determine the efficiency and scalability of query optimization, particularly when searching for minimal-cost execution strategies in complex queries with multiple joins and selection predicates. Join DAGs support both pre-computed and incremental formation, enabling rapid generation and refinement of optimal join plans as query workloads evolve or as selections are "sprinkled" throughout the query plan [0202035].

1. Formal Definitions and Core Structures

Given a relational schema $R = \{R_1, R_2, \dots, R_n\}$, the join graph $G = (V, E)$ is an undirected graph with $V$ as the relations and $E = \{(R_i, R_j, \theta_{ij})\}$ where join predicates $\theta_{ij}$ exist. The join DAG expands this, with directed nodes representing all intermediate joins built over subsets $S(u) \subseteq R$.

• Leaf nodes: Singleton sets $\{R_i\}$ corresponding to scans of base relations.
• Internal nodes: Each with a scope $S(u) = X \cup Y$ where $X \cap Y = \emptyset$ and some join predicate connects $X$ and $G = (V, E)$0.
• Root node: Scope is $G = (V, E)$1, representing the complete query result.

For every subset $G = (V, E)$2, at most one node exists for each unique join result, maximizing subplan sharing and reducing combinatorial blowup typical of naive join enumeration [0202035].

2. Join DAG Construction Algorithms

2.1 Pre-computation (Full Enumeration)

The standard approach constructs the join DAG bottom-up, iterating over all subsets of $G = (V, E)$3 in increasing cardinality. For each subset $G = (V, E)$4, all partitions into disjoint $G = (V, E)$5 are examined, and nodes plus edges are added if a join edge exists between the two subsets. Afterward, a dynamic programming pass annotates each node with its minimal construction cost:

$\theta_{ij}$2

The resulting join DAG enables exponential sharing: all distinct orderings of joins among the same relations reuse the same intermediate nodes [0202035].

2.2 Incremental (History) Join DAG Formation

For dynamic, workload-driven optimization, the history join DAG supports incremental updates. When a new query with $G = (V, E)$6 arrives, only the minimal necessary subgraph is constructed, leveraging existing nodes where possible. The incremental algorithm scans for new subsets missing from the current DAG, creates nodes for those, and recomputes costs in affected subgraphs:

$\theta_{ij}$3 This supports efficient adaptation to schema evolution or repeated/related queries [0202035].

3. Cost Models and Complexity

Each join DAG node is annotated with cost estimates (often cardinality-based) and outputs, propagated bottom-up:

• For a join producing node $G = (V, E)$7 from $G = (V, E)$8:
  • $G = (V, E)$9
  • $V$0,
  • where $V$1 absorbs per-tuple resource costs.

Complexity is dictated by the number of subsets (nodes) and possible partitions per subset:

• Nodes: $V$2
• Edges: up to $V$3
• Total time: $V$4 due to enumerating all binary partitions for all subsets.

Incremental construction and caching can amortize this cost in query workloads with recurring access patterns or modest query width [0202035].

4. Selection Placement and Plan Refinement

Selection predicates are "sprinkled"—assigned as early as possible to minimize intermediate result sizes:

• If $V$5 references just $V$6: annotate leaf node $V$7.
• Otherwise, place $V$8 at the join DAG node whose scope covers all referenced tables, lowest in the DAG.

The cost model is then adjusted:

• For selection at $V$9 with selectivity $E = \{(R_i, R_j, \theta_{ij})\}$0:
  • Update $E = \{(R_i, R_j, \theta_{ij})\}$1
  • Update all upstream costs to reflect the reduced output size.

This refinement can change the optimal plan, as introducing a highly selective predicate early can change cardinality and join order preferences [0202035].

5. Applications and Experimental Results

Join DAGs provide a compact representation for searching optimal join orders and efficiently supporting multiple-query optimization, including selection and materialized view selection in data warehouse environments. Empirical analysis on TPC-D/H query sets demonstrates that join DAG-based optimization outperforms traditional AND/OR DAG techniques in both preprocessing cost and plan quality [0202035].

The approach directly benefits systems requiring:

• Exhaustive plan enumeration without redundant computation,
• Adaptive reuse in evolving query workloads,
• Optimized plan selection in the presence of complex selection and join conditions.

6. Worked Example and Practical Workflow

Consider a schema $E = \{(R_i, R_j, \theta_{ij})\}$2 with joins $E = \{(R_i, R_j, \theta_{ij})\}$3 and $E = \{(R_i, R_j, \theta_{ij})\}$4:

• DAG construction identifies nodes for every nonempty subset (e.g., $E = \{(R_i, R_j, \theta_{ij})\}$5), with plan edges reflecting joinability.
• Cost calculation selects, for $E = \{(R_i, R_j, \theta_{ij})\}$6, the lower-cost of possible join sequences (e.g., $E = \{(R_i, R_j, \theta_{ij})\}$7 vs. $E = \{(R_i, R_j, \theta_{ij})\}$8), given cardinalities and selectivities.
• Incremental update supports dynamic addition of join predicates (e.g., introducing $E = \{(R_i, R_j, \theta_{ij})\}$9), by reusing existing nodes and only building new joins involving novel relations.
• Selection refinement: Pushing $\theta_{ij}$0 to $\theta_{ij}$1, recalculates affected costs and may alter the optimal join order.

These steps collectively enable implementers to instantiate a complete join optimization pipeline leveraging the join DAG paradigm, as illustrated in [0202035].