[zzylol]

Why

#954: top-k reuse and the summary-capability rule both share one producer at a need that covers every reader (the largest k; each size parameter's strictest value; a common pane grid with the longest window), and each reader derives its own result from it. They had two separate candidate-generation loops in the memo. This PR gives them one path, so that the next case (#951's shared scan, a group-by union) is a new implementation of that path, not a third loop.

What

There is no behavior change. The memo's top-k reuse and shared-size / shared-pane configurations now generate their candidates through add_shared_producer_candidates. The candidates they produce are identical to main's, which a new test pins with hashes recorded on main.

Case	Old code path	New covering / derive	Status
exact top-k reuse	memo/rules/topk.rs add_topk_candidates (its own loop over topk_reuse_candidates)	TopKRankings: covering = the ranking Limit(k_max) ▸ Sort; derive = Limit(k) ▸ Project via append_producer / append_reader	unified
summary capability (shared sizes)	memo/rules/state_configurations.rs expand_configurations, size branch	SummaryStates: covering = StateCovering::Size from state_size_configurations; derive = with_resized_build	unified
window composition (shared panes)	same function, pane branch	SummaryStates: covering = StateCovering::Panes from pane_configurations_before; derive = with_pane_chain	unified
percentile ranks (#922)	ir::cse interning of equal windows over a scan	none: equal source windows become one memo group	left in ir::cse: the producer is the identical window, so no candidate is generated
identical expression	ir::cse / memo group identity	none: the trivial case	left in ir::cse, as #954 states

Not in this PR:

• the whole-workload Pass 2 functions in asap_aware_cse.rs (summary_capability_pass2_candidates, topk_reuse_pass2_candidates), which Reorganize by stage: one memo-based Pass 2, Stage 1 finishes the memo, deployment inputs split by stage, asap-planner as the only entry point #958 plans to delete once the memo path covers them;
• the docs: propose workload-wide planning, summary sharing, and materialization #509 design doc's rule table, which belongs in a docs PR.

How

memo/rules/shared_producer.rs holds the driver and the SharedProducer trait (crate-private):

1. sets lists a kind's readers, already grouped into sets that can share. Each kind groups its own readers.
2. A set spanning two or more groups gets its coverings.
3. Each reader gets derive for each covering. derive adds nothing when the covering does not serve the reader, so each kind filters its own readers.

The two implementations are the old code moved into those methods, with the order of reads, writes and deduplication preserved:

• SummaryStates groups by its compatible check. For a set that shares panes, sets also numbers each reader's normalized pane layout (StateNeed::normalized_layout). The numbers continue across sets, so the request deduplication needs no per-set reset, and coverings takes &self.
• TopKRankings returns one set per topk_reuse_candidates result, each reader carrying the set's ranking. Its covering is that ranking plus the set's groups. The ranking is interned in the first reader's derive; later readers get the same producer group back, because append_producer is idempotent.

Key code interfaces added / modified

memo/rules/shared_producer.rs (new; crate-private, pub(in crate::memo))

/// One reader of a kind of shared producer: its memo group and its need.
pub(in crate::memo) struct Reader<N> {                                   // new
    pub group: usize,                                                    // new
    pub need: N,                                                         // new
}

/// A kind of producer several readers can share.
pub(in crate::memo) trait SharedProducer {                               // new
    /// What one reader requires of the producer.
    type Need;
    /// A producer's need that serves several readers at once.
    type Covering;
    /// The memo's readers of this kind, in sets whose members can all read
    /// one producer; in memo order.
    fn sets(&mut self, memo: &CandidateMemo, deadline: Option<Instant>)
        -> Result<Vec<Vec<Reader<Self::Need>>>, StateGroupExpansionError>;
    /// The coverings to offer the readers of `set`.
    fn coverings(&self, set: &[Reader<Self::Need>], deadline: Option<Instant>)
        -> Result<Vec<Self::Covering>, StateGroupExpansionError>;
    /// Adds `reader`'s derivation from the producer at `covering`, if that
    /// producer serves it; the number of candidates added.
    fn derive(&mut self, memo: &mut CandidateMemo, reader: &Reader<Self::Need>,
        covering: &Self::Covering) -> Result<usize, StateGroupExpansionError>;
}

/// Whether `set`'s readers belong to two or more groups.
pub(in crate::memo) fn spans_groups<N>(set: &[Reader<N>]) -> bool;     // new

/// Gives every reader of a set spanning two or more groups its derivation
/// from each of the set's coverings.
pub(in crate::memo) fn add_shared_producer_candidates<P: SharedProducer>(
    memo: &mut CandidateMemo, producer: &mut P, deadline: Option<Instant>,
) -> Result<usize, StateGroupExpansionError>;                            // new

Covering is a separate type from Need, unlike the sketch in #954. A pane covering is a whole configuration (grid, longest window, family), not one reader's need.

memo/rules/topk.rs: add_topk_candidates keeps its signature and now calls the driver with TopKRankings (new, private).

memo/rules/state_configurations.rs: add_state_configuration_candidates_in_domain keeps its signature and now calls the driver with SummaryStates (new, private). The private Reader struct is renamed StateNeed and gains normalized_layout; StateCovering is new and private. TopKRankings's need is the set's ranking node and its covering SharedRanking (ranking plus reader_groups); both private.

Usage, end to end:

1. Input: the PromQL workload topk(3, sum_over_time(m_gauge[2m])) plus topk(10, sum_over_time(m_gauge[2m])), every 60 s, exact.
2. Pass 1: try_populate_pass1 builds the memo.
3. Expansion: expand_concrete_summary_state_groups_in_domain runs add_topk_candidates, which calls add_shared_producer_candidates(memo, &mut TopKRankings { .. }, deadline).
   • sets returns one set: the two top-k groups, each with the reuse set's ranking Limit(10) ▸ Sort.
   • coverings returns that ranking with the two groups.
   • derive interns it once and adds Limit(3) ▸ Project and Limit(10) ▸ Project readers with origin TopKReuse.
4. Output: plan selection receives the same memo as on main: 313 candidates with the same hash. The test top_k_reuse_candidates_are_unchanged checks this.

Major algorithm changes

None in results: candidate generation for these three cases is restructured onto one driver, and its outputs are unchanged. Complexity changes slightly: the top-k path now collects queries and calls append_producer once per reader instead of once per set, so a set of R readers does R linear scans of the memo groups instead of one; repeated calls find the existing producer group. Top-k sets are small, so this is negligible. SummaryStates::derive checks that the covering serves the reader before cloning the candidate, so skipped pairs cost no clone.

Before this PR

Two loops generated shared-producer candidates: add_topk_candidates and expand_configurations. Each had its own grouping, covering and derivation code.

After this PR

One driver generates them. A new case implements SharedProducer (sets, coverings, derive) and calls add_shared_producer_candidates.

Verification

• Behavior lock (memo/shared_producer_snapshot.rs, new): it hashes each expanded memo in memo order: every group's node, children, parents, queries and roots, and every candidate's origin, budget share, implemented groups, child groups and node. Order matters because the search's tie-breaks depend on it.
  • Recorded on main (d4152bce): top-k (313 candidates, 16940643818053118362), shared sizes (508, 7457272222287953080), shared panes (729, 15532247561651645380), two top-k sets next to a pane set (994, 9213568444657927922; pins the order sets are expanded in).
  • Branch: identical.
  • The test also checks that the top-k workload yields TopKReuse candidates and the pane workload yields pane chains, so each case is exercised.
• On the branch (rebased on d4152bce): cargo test -p asap-logical-asap-optimization --lib: 229 passed, snapshot hashes unchanged.
• Integration tests on the branch, all passed:
  • reuse_rules 7
  • sharing_issue_regressions 12 ([Bug] Identical exact query-time aggregates are not shared across queries #922/[Bug] A nested shorter window of an exact sum does not reuse the newest panes of the longer window's chain #924/[Bug] The same query at a longer repeat interval recomputes instead of reusing the shorter-interval result #925 cost bounds included)
  • sql_two_percentiles 4
  • tumbling_pane_merge 13 (1 ignored, as on main)
  • identical_exact_queries 2
  • operator_sharing (both tests ignored on main too)
• Independent review: an independent reviewer compared main and this branch on five extra multi-set workloads (two pane sets on different metrics, mixed sum/max panes, quantile panes on two metrics, two size sets, mixed top-k plus panes): same counts and hashes on all five. Numbering normalized layouts per set instead of globally (a deliberate mutation) fails the size and pane snapshots (508 → 348, 729 → 489), so the test catches that risk.
• Style: cargo fmt --all and cargo clippy -p asap-logical-asap-optimization --all-targets --all-features -- -D warnings are clean (stable toolchain).

Part of #954

🤖 Generated with Claude Code

[zzylol]

@milindsrivastava1997 FYI