Problem
tools/dag-viewer was restyled to match ProjectASAP/bgp-query-dag-explorer's
visual language, but it kept the existing interaction model for viewing
multiple loaded queries: tabs to switch between them one at a time, plus
hash-based shared-subtree highlighting (an outline ring on nodes whose
(kind, detail, children) hash matches a node in another loaded query — see
the doc comment on crates/ir/src/dag_export.rs).
There's no way to see two or more QueryExpr graphs at once — side by side,
or merged into a single view showing what's shared vs. query-specific. The
reference repo has this (its Compare and Union modes), but its approach was
built for BGP's queries, which are each a flat, mostly-linear list of steps.
QueryExpr graphs are real recursive DAGs with branching at arbitrary depth
(Merge with N children, Join/SetOp/BinaryOp with two, LetBinding
with two structurally different children), so the reference's approach
doesn't carry over as-is.
This also intersects with asap_plan::cse::dedupe_subtrees: that pass isn't
wired into any end-to-end multi-root planning path today, so there's no real
CseWorkloadPlan to visualize yet. Once it is, a multi-query view is where
its bindings/Ref output would naturally be rendered as converging edges,
instead of (or alongside) today's hash-based shared-subtree proxy.
Problem
tools/dag-viewerwas restyled to matchProjectASAP/bgp-query-dag-explorer'svisual language, but it kept the existing interaction model for viewing
multiple loaded queries: tabs to switch between them one at a time, plus
hash-based shared-subtree highlighting (an outline ring on nodes whose
(kind, detail, children)hash matches a node in another loaded query — seethe doc comment on
crates/ir/src/dag_export.rs).There's no way to see two or more
QueryExprgraphs at once — side by side,or merged into a single view showing what's shared vs. query-specific. The
reference repo has this (its Compare and Union modes), but its approach was
built for BGP's queries, which are each a flat, mostly-linear list of
steps.QueryExprgraphs are real recursive DAGs with branching at arbitrary depth(
Mergewith N children,Join/SetOp/BinaryOpwith two,LetBindingwith two structurally different children), so the reference's approach
doesn't carry over as-is.
This also intersects with
asap_plan::cse::dedupe_subtrees: that pass isn'twired into any end-to-end multi-root planning path today, so there's no real
CseWorkloadPlanto visualize yet. Once it is, a multi-query view is whereits
bindings/Refoutput would naturally be rendered as converging edges,instead of (or alongside) today's hash-based shared-subtree proxy.