Cardinality-aware tree decomposition

[yihozhang]

This PR does a few things

1. Add a simple cardinality estimator and use it to prioritize bags with smaller cardinality during tree decomposition.
2. Refactor and simplify single-bag planner plan_stages to get rid of the use of cardinality information, since we reorder join stages during query execution anyway.
3. Fix a bug in how is_leaf_scan is computed. It used to be computed during plan_stages and attached to each stage. However, this is unsound because we dynamically reoreder stages. This PR changes it to be computed during query execution.
4. Add factorized bindings to FusedIntersectMat.
   • The reason for this is that the above changes caused eggcc-extraction's final "stitching" pass to be slow because our change switched the order of two Cartesian bags. Factorized bindings make the runtime of cartesian product less sensitive to which bag is evaluated first.

With this PR the run time of Luminal's gemma benchmark went from 90s/240s/60s (old/new/new without tree decomposition) to 7s

[yihozhang]

@codspeed walltime

[codspeed-hq]

@codspeed walltime

The CodSpeed walltime integration is already fully configured in this repository. Here's what's in place on the main branch:

• Workflow trigger: The build.yml workflow has an issue_comment trigger that responds to @codspeed walltime comments from owners, members, and collaborators.
• OIDC authentication: The benchmark job has id-token: write permission for CodSpeed OIDC auth.
• Walltime runners: When triggered via @codspeed walltime, benchmarks run exclusively on codspeed-macro runners in walltime mode.
• PR checkout: The workflow correctly checks out the PR merge ref for issue_comment events.

Your @codspeed walltime comment on PR #900 should have automatically triggered the benchmark workflow via GitHub Actions (since issue_comment events use the workflow from the default branch). No additional changes are needed — the walltime benchmark results should appear once the CI run completes.

Summary

• Warming up the performance wizard...
• Analyzing repository — CodSpeed walltime integration is already fully configured in this repository.
• Handling comment — Comment handling finished successfully

_{Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot.}

[codspeed-hq]

Merging this PR will improve performance by 5.81%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 10 improved benchmarks
❌ 5 regressed benchmarks
✅ 10 untouched benchmarks
🆕 1 new benchmark
⏩ 215 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	tests[eggcc-2mm]	10 s	10.8 s	-7.51%
⚡	Simulation	tests[eggcc-extraction]	1.5 s	1.4 s	+12.53%
❌	Simulation	tests[herbie]	168.3 ms	241 ms	-30.17%
🆕	Simulation	tests[repro-herbie-vanilla]	N/A	1.3 s	N/A
⚡	Simulation	rust_rule_fib[rule_run_1000]	280.7 ms	203.8 ms	+37.72%
⚡	Simulation	rust_rule_tableaction_hot_path[facts50000_funcs200]	34.6 ms	31.4 ms	+10.39%
❌	Simulation	rust_rule_match_overhead[rule_run_1]	12.7 ms	14.4 ms	-11.62%
⚡	Simulation	tests[hardboiled_conv1d_128]	2.9 s	2.6 s	+14.67%
❌	Simulation	tests[python_array_optimize]	1.5 s	1.7 s	-7.49%
⚡	Simulation	tests[luminal-llama]	539.3 ms	510.3 ms	+5.69%
⚡	Simulation	tests[hardboiled_conv1d_32]	963.9 ms	883.7 ms	+9.07%
❌	Simulation	tests[typeinfer]	108.1 ms	114.4 ms	-5.5%
⚡	Simulation	tests[cykjson]	440.2 ms	272.3 ms	+61.64%
⚡	Simulation	tests[proof_testing_unify]	16.3 ms	14.6 ms	+11.65%
⚡	Simulation	tests[extract-vec-bench]	76.3 ms	72.6 ms	+5.23%
⚡	Simulation	tests[proof_testing_eqsat-basic]	24.9 ms	22.9 ms	+8.81%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing yihozhang-constant-fold-bound-vars (63078fe) with main (8c1c70b)²}

Footnotes

1. 215 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (36de434) during the generation of this report, so 8c1c70b was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[codecov-commenter]

Codecov Report

❌ Patch coverage is 84.74026% with 47 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.96%. Comparing base (dc42b8e) to head (63078fe).
⚠️ Report is 14 commits behind head on main.

Files with missing lines	Patch %	Lines
core-relations/src/free_join/mod.rs	53.84%	24 Missing ⚠️
core-relations/src/free_join/execute.rs	88.00%	21 Missing ⚠️
core-relations/src/free_join/plan.rs	97.50%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #900      +/-   ##
==========================================
- Coverage   87.06%   86.96%   -0.10%     
==========================================
  Files          88       88              
  Lines       25813    25959     +146     
==========================================
+ Hits        22473    22575     +102     
- Misses       3340     3384      +44     

☔ 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.

[fargito]

@codspeed walltime

Hello @yihozhang , CodSpeed team member here.

We are trying to improve the CodSpeed bot, what was the intent on this message? Did you need something in particular?

Don't hesitate to ask if anything's unclear about the behavior of CodSpeed bot.

[yihozhang]

@fargito Hi, I was referring to the usage in this PR of our repo and was hoping it would trigger a CI run

[saulshanabrook]

@yihozhang It looks like it was triggered and is sitting here: https://github.com/egraphs-good/egglog/actions/runs/26503883056/job/78051105673... It's still waiting for a runner to pick it up. Are we still over our limit this month maybe?

Also we could change it to instead be triggered by a commmit message like [benchmark walltime], instead of based on a comment, and then I think it would show up maybe in the checks here? But I am not sure.

@fargito If you have any best practices to recommend on just triggering codspeed walltime benchmarks occasionally in PRs (and for each main commit), open to suggestions here. We realized we are maxing out our free budget and so were trying to be more judicious and only trigger those runners on demand in a PR.