Skip to content

sql: Refactor MapFilterProject, MfpPlan, and SafeMfpPlan to have parameter with trait#36759

Open
mgree wants to merge 1 commit into
MaterializeInc:mainfrom
mgree:stable-lir-mfp-refactor
Open

sql: Refactor MapFilterProject, MfpPlan, and SafeMfpPlan to have parameter with trait#36759
mgree wants to merge 1 commit into
MaterializeInc:mainfrom
mgree:stable-lir-mfp-refactor

Conversation

@mgree
Copy link
Copy Markdown
Contributor

@mgree mgree commented May 27, 2026

Motivation

Second PR pulled from #36544.

Description

MapFilterProject (and its friends, MfpPlan and SafeMfpPlan---the "MFP" family) are used at both the MIR and LIR level. To separate LIR cleanly from MIR, we need to be able to work with MFPs at both levels.

This change parameterizes these types and introduces a trait OptimizableExpr that allows us to work independently of the MIR type. It is not the prettiest trait, but I don't see how to work around this (without a much more intensive overhaul of how we process MFP-like structures in LIR). See also: https://linear.app/materializeinc/issue/SQL-319/mfp-like-structures-in-lir-are-optimized-late.

Verification

Pure refactor, CI green.

@mgree mgree changed the title refactor: Parameterize MapFilterProject, MfpPlan, and SafeMfpPlan; add trait sql: Refactor MapFilterProject, MfpPlan, and SafeMfpPlan to have parameter with trait May 27, 2026
@mgree mgree marked this pull request as ready for review May 27, 2026 21:15
@mgree mgree requested a review from a team as a code owner May 27, 2026 21:15
@ggevay
Copy link
Copy Markdown
Contributor

ggevay commented May 28, 2026

Triggered the random query subset of Nightly: https://buildkite.com/materialize/nightly/builds/16607

Copy link
Copy Markdown
Contributor

@ggevay ggevay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, if Nightly is green

Comment thread src/expr/src/linear.rs
expr.visit_pre(|e| {
if let MirScalarExpr::Column(i, _name) = e {
reference_count[*i] += 1;
expr.visit_pre(&mut |e| {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor thing: originally, this was MSE's visit_pre, which is written iteratively (the worklist stuff) to avoid recursion limit issues, while the new code is calling the Visit trait's visit_pre, which is Stacker-based. So, we now could newly panic on a recursion limit error. I'm wondering if the Visit trait's implementation could also be changed to be iterative.

(And the same at the below visit_pre call.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants