feat(queryopt): set simplification optimizer

[jzelinskie]

Description

Adds a new query-plan optimizer, set-simplification, that eliminates structurally redundant nodes from outline trees using ten set-theoretic laws. The optimizer runs as a standard pass (registered in StandardOptimizations) and requires no cardinality or schema information — all laws hold unconditionally.

Laws implemented

Union

• A ∪ A = A (idempotency)
• A ∪ (A ∩ B) = A (absorption)
• A ∪ (A − B) = A (complement-absorption)

Intersection

• A ∩ A = A (idempotency)
• A ∩ (A ∪ B) = A (absorption)
• Y ∩ (A − C) = ∅ when Y ⊆ C (complement-annihilation)

Exclusion

• X − A = ∅ when X ⊆ A (annihilation, generalized from A − A = ∅)
• (A ∪ B) − Y = B − Y when A ⊆ Y (left-pruning)
• A − ∅ = A (null-identity)

Structural prerequisite

• (A ∪ B) ∪ C = A ∪ B ∪ C and (A ∩ B) ∩ C = A ∩ B ∩ C (associativity flattening, runs first so absorption sees all
  peers)

Implementation notes

The optimizer is structured as one function per law, all composed via MutateOutline in a single bottom-up pass. Subsumption tests reuse the existing isSubsumedBy predicate; no new structural predicates were introduced.

A − ∅ = A lives in the absorption mutation chain rather than in the shared NullPropagation utility. NullPropagation is also called by reachability-pruning, which intentionally leaves A − ∅ intact (the null subtrahend is a meaningful pruning artifact in that context).

The optimizer was initially named absorption-idempotency; it is renamed to set-simplification to reflect the full scope of rules it now covers.

Testing

Added unit tests for everything including those missing for NullPropagation.
LMK if I need to add any other kind of tests when adding optimizers

References

• Wikipedia for set theory absorption

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.63%. Comparing base (ee7c9a7) to head (40df164).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3051      +/-   ##
==========================================
+ Coverage   75.52%   75.63%   +0.12%     
==========================================
  Files         503      504       +1     
  Lines       61820    62045     +225     
==========================================
+ Hits        46683    46923     +240     
+ Misses      11722    11708      -14     
+ Partials     3415     3414       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tstirrat15]

LGTM but would like barak's eyes on it as well

[tstirrat15]

Do we have a means of constructing a list of optimizers at startup time rather than taking the registration approach? This smells like it's going to turn into z-index eventually.

[jzelinskie]

This is definitely a place that could use work. I think for now it'd probably help to just have a central list where optimizers are registered, similar how to we register gRPC middleware. If it ever got too confusing doing that, it'd make sense to explicitly add "before" and "after" properties to each optimizer and let the system compute the order based on those (kind like systemd startup ordering)

[josephschorr]

@jzelinskie I'd say we do the before/after now: its going to rapidly become untenable, so I recommend as a followup PR

[tstirrat15]

See comments

[tstirrat15]

Is this potentially expensive for an intersection at the top of a bunch of deep trees? Or are we expecting that the shapes we're working with here aren't going to be problematic in that way?

[jzelinskie]

I didn't evaluate the cost of outline compares when drafting this. I assumed they were cheap, but that's definitely not the case.

Here's what Claude thinks about this:

unionAbsorption complexity at a single Union node:

eliminateRedundantChildren does O(n²) pair comparisons. For each (y, x) pair in shouldDrop:

for _, factor := range intersectionFactors(x) {             // O(k) factors of x
    if !slices.ContainsFunc(y.SubOutlines, factor.Equals) { // O(m) calls per factor
        return false
    }
}

Each factor.Equals call invokes OutlineCompare (outline.go:428), which recursively walks the entire subtree — O(T) where T is subtree size. There is no memoization or hash shortcut.

So total cost at a Union node: O(n² × k × m × T)

If you have Union[Intersection[A,B], Intersection[A,B,C], ...] where A, B, C are deep trees, checking whether A.Equals(A) does a full tree walk each time — even comparing the same subtree to itself.

The early exits in OutlineCompare (line 432: type first, then args) help when subtrees differ near the root, but for the absorption case the trees being compared will often share a common prefix all the way down.

The fix: Precompute a Serialize() hash per node before running mutations, and use it as an O(1) equality fast path. Serialize() (outline.go:573) already exists and CanonicalKey.Hash() (line 53) wraps xxhash. The blocker is that Outline is passed by value with no cached hash field, and ID is only populated post-canonicalization.

The cleanest option is adding a lazily-precomputed serialHash uint64 field to Outline, set during the pre-optimization FillMissingNodeIDs pass, and short-circuiting OutlineCompare with a hash comparison first.

I think this suggestion is a way bigger change that needs feedback from @barakmich.

[tstirrat15]

Is this not satisfied by construction? Or are we being defensive here?

[jzelinskie]

This was just being defensive in case of refactoring.