Run ProjectionPushdown after the last RelationCSE

[ggevay]

Edit: I've added the lts-backport-v25.1 label, but if this turns out to be too annoying to cherry-pick, then it's ok to skip this, as it's just a performance improvement.

This adds a call to ProjectionPushdown after the last call to RelationCSE. As explained in a code comment:

// `RelationCSE` can create new points of interest for `ProjectionPushdown`: If an MFP
// is cut in half by `RelationCSE`, then we'd like to push projections behind the new
// Get as much as possible. This is because a fork in the plan involves copying the
// data. (But we need `ProjectionPushdown` to skip joins, because it can't deal with
// filled in JoinImplementations.)

Slack discussion here:
https://materializeinc.slack.com/archives/C07SUTL7JMQ/p1741358397379089?thread_ts=1741341927.561309&cid=C07SUTL7JMQ

It's guarded by a feature flag as a precaution, but I've enabled it by default, as it's hard to imagine this hurting plans.

The first commit is the actual functionality, while the second commit just adds the feature flag.

Motivation

• This PR increases performance.

Tips for reviewer

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

[mgree]

Looks good to me: code is simple enough and SLTs look good.

The join skipping is an unwelcome bit of complexity (it's almost the same logic), but here we are. Perhaps an issue for another time, but how hard would it be to actually look at JoinImplementations here?

[ggevay]

Thanks for the review!

The join skipping is an unwelcome bit of complexity (it's almost the same logic), but here we are. Perhaps an issue for another time, but how hard would it be to actually look at JoinImplementations here?

It wouldn't be impossible:

• We'd have to attend to all the scalar expressions in the JoinImplementation enum.
• We'd have to attend to the ArrangeBys below the joins.
• (I think JoinInputCharacteristics are unchanged. E.g., key fields are demanded, so key length is not changing.)
• (I think we don't need to touch the Rows that are inside JoinImplementation::IndexedFilter, because those fields are involved in join conditions, so are demanded.)

One reason for which I decided to not go for JoinImplementation is that in the long run we want to move the JoinImplementation transform to just before the MIR lowering, and then manipulating the JoinImplementation enum in other transforms won't be needed anymore.

(Running Nightly now, and then merging.)

[ggevay]

It's good that I've run Nightly, because there is an EXPLAIN output change 😅 Discussing here.

[def-]

Edit: I've added the lts-backport-v25.1 label, but if this turns out to be too annoying to cherry-pick, then it's ok to skip this, as it's just a performance improvement.

There is a bunch of conflicts indeed. I'm not sure if we should backport these kinds of changes in general, since there is also some risk for them.