A HelixQL query with four correlated signals has 24 possible join orders. The planner doesn't try them all — here's the search it actually runs.

Join order matters enormously for multi-way correlation queries — joining metrics, traces, logs, and profiles in the wrong order can mean materializing an intermediate result 100x larger than necessary. With n relations there are n! possible orders, which gets expensive to search exhaustively past 4-5 inputs. HelixQL's planner uses a bounded dynamic-programming search instead.

Why exhaustive search doesn't scale

Most HelixQL queries join 2-3 signal types, where exhaustive search (6 or 24 orderings) is trivially cheap — under a millisecond of planning time. But queries correlating 5+ sources, which do happen in complex incident investigations, would require searching 120+ orderings if done naively, each requiring a cost estimate.

The DP approach

The planner builds up optimal join orders for subsets of relations incrementally: it finds the best plan for every pair, then extends each to the best plan for every triple that includes an already-optimal pair, and so on. This bounds the search to roughly 2^n subsets rather than n! full orderings — for 5 relations, that's 32 subset evaluations instead of 120 full permutations.

from traces  | where service == 'checkout-api'
| join (from logs | where level == 'error') on trace_id
| join (from metrics | where name == 'db.query.duration') on trace_id
| join (from profiles | where trace_id != null) on trace_id
# planner evaluates subset costs bottom-up: pairs, then triples, then the full 4-way join

Pruning beyond DP

Even 2^n subset evaluation gets expensive past 7-8 relations, which is rare but not impossible in exploratory investigation queries. Past that threshold, the planner switches to a greedy heuristic — always join the two smallest estimated intermediate results next — which sacrifices optimality for bounded planning time. We cap planning time itself at 50ms; if DP search would exceed that budget, it falls back to greedy before that budget is spent.

Measured plan quality

Against a benchmark of 30 real-world multi-signal correlation queries pulled from customer incident investigations, the DP-based planner found the truly optimal join order in 27 of 30 cases (the other 3 were close, within 15% of optimal cost), and did so in under 8ms of planning time for the median query, versus roughly 40ms if we forced exhaustive search on every query regardless of size.

  • DP-based join order search bounds planning to roughly 2^n subsets instead of n! full permutations.
  • Planning time is capped at 50ms; past that, the planner falls back to a greedy smallest-first heuristic.
  • On 30 real multi-signal queries, DP search found the true optimum in 27 cases, median planning time 8ms.