Refactor out inlined values in builtin materialized views - #39468
Open
SangJunBak wants to merge 7 commits into
Open
SangJunBak wants to merge 7 commits into
SangJunBak wants to merge 7 commits into
Conversation
SangJunBak
added this pull request to stack #38849
October 2, 2026 00:20
SangJunBak
changed the title
SangJunBak
force-pushed
the
jun/sql-653-static-builtin-values-in-mv-fingerprint
branch
from
October 2, 2026 03:32
3db1f61 to
03701c4
Compare
SangJunBak
force-pushed
the
jun/sql-653-static-builtin-values-in-mv-fingerprint
branch
from
October 2, 2026 04:40
03701c4 to
631ddf2
Compare
SangJunBak
force-pushed
the
jun/sql-653-static-builtin-values-in-mv-fingerprint
branch
2 times, most recently
from
October 5, 2026 16:13
0ce5fa8 to
a3430b2
Compare
Base automatically changed from
jun/sql-499-convert-item-metadata-tables-to-catalog-views
to
main
October 6, 2026 03:01
…exes - We need to extract this into its own view such that later, we can extend and reuse mz_builtin_indexes without changing the schema of mz_indexes since it's an mz_catalog relation and stable - Initially we thought we had to inline the builtin VALUES into the materialized view, otherwise a silent change to an upstream view (i.e. mz_builtin_indexes) would silently create an error in the materialized view. However we've since realized that as long as the schema of the upstream view stays the same, any updates to it will simply sink into the materialized view. If the schema were to change however, e.g. we ASSERT NOT NULL on the mv but have the upstream view provide a NULL value, then the mv would error when queried. However, we have tests that actually query each builtin so this regression would be caught.
…indexes - Because we don't need to inline VALUES into the DDLs of our builtin materialized views, we can create a new mz_builtin_log_indexes such that both mz_sources and mz_indexes can query it rather than get sent an iterator of the builtin logs. - We simply extract inline VALUES code into a new builtin view called mz_builtin_logs then reference it in mz_builtin_indexes - This comes with the nice benefit of not having to dynamically generate each mz_indexes and define the order statically. - We can also turn make_mz_indexes into a static MZ_INDEXES like the rest of our builtins - In a later commit, we'll making the same refactor for mz_sources
- In mz_sources, rather than inline the builtin sources and logs as a VALUES list, read them from mz_builtin_sources - mz_builtin_sources already existed inside "make_builtin_sources", however it was just never used and was dead code. This is why we delete code in make_mz_sources but don't see a positive diff in this commit. However if you were to look inside make_builtin_sources, the same code we deleted exists there.
…tin_log_indexes - Move `privileges` to `mz_builtin_log_indexes` from `mz_builtin_sources` - Instead of embedding the builtin logs to mz_sources, just join on `mz_builtin_log_indexes`
Simply move make_mz_sources to a static mz_sources to remove an unnecessary function call.
Given we're not sharing iterators across these view generators, we can simplify the code further.
SangJunBak
force-pushed
the
jun/sql-653-static-builtin-values-in-mv-fingerprint
branch
from
October 6, 2026 03:02
a3430b2 to
b3e9ac9
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I'd recommend this PR commit by commit. All of this is entirely a refactor and most is just moving code around.
Motivation
Closes sql-653
Description
Should have no customer facing changes. The biggest change is instead of inlining builtin values into the fingerprint, we can use our original pattern of using upstream "mz_builtin_*" views. Initially we thought we had to inline the builtin VALUES into the materialized view, otherwise a silent change to an upstream view (i.e. mz_builtin_indexes) would silently create an error in the materialized view. However we've since realized that as long as the schema of the upstream view stays the same, any updates to it will simply sink into the materialized view. If the schema were to change however, e.g. we ASSERT NOT NULL on the mv but have the upstream view provide a NULL value, then the mv would error when queried. However, we have tests that actually query each builtin so this regression would be caught.
Verification
A proof point of this working is mz_object_dependencies. It is an mv that references an upstream view
mz_object_dependencies_rawthat's constantly changing. This has been in production for a while but things are healthy due to what I stated prior.