Skip to content

Conversation

@teskje
Copy link
Contributor

@teskje teskje commented Dec 2, 2025

This PR adds a new mz_replacements builtin table, exposing the replacement MV relationship. It also adds a replacing column to the SHOW MATERIALIZED VIEWS output, fueled by the new mz_replacements table.

Motivation

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.

Once materialized views can have multiple historical storage collections
associated with them, we'll need to make sure to drop all of those when
dropping a materialized view. There is always only a single compute
collection to drop.

This commit ensures we'll do the right thing and also simplifies the
item dropping code a bit in the process: Instead of keeping track of
indexes/MVs/CTs to drop, we instead only track compute and storage
collections to drop. Doing so allows deleting a bunch of duplicate code.
This commit adds a feature flag to gate the creation and application of
replacement materialized views. It's disabled by default and enabled in
CI.
@teskje teskje force-pushed the mz_replacements branch 2 times, most recently from 77a086d to 5a65c20 Compare December 3, 2025 14:26
When a replacement MV is applied, the catalog is updated by dropping the
replacement and updating the target MV with a new version. This
transfers both the replacement's compute and storage collection to the
target MV, so they should not be dropped. The implication application
logic must thus be extended to account for that.
For compute collections, it is wrong to assume that all GlobalIds
associated with a catalog entry (specifically an MV catalog entry) also
map to live compute collections. Instead, only the "write GlobalId" has
a live compute collection. Compute collections that were previously
maintaining the catalog item have likely been dropped already.
This commit adds a new `mz_replacements` builtin table, exposing the
replacement MV relationship. It also adds a `replacing` column to the
`SHOW MATERIALIZED VIEWS` output, fueled by the new `mz_replacements`
table.
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.

1 participant