Conversation
kay-kim
force-pushed
the
altermv-tutorial
branch
from
1f93e61 to
36d7dfc
Compare
kay-kim
force-pushed
the
altermv-tutorial
branch
from
3cc9e0c to
97c967f
Compare
|
|
||
| {{< note >}} | ||
|
|
||
| {{% include-headless "/headless/replacement-views/querying-replacement-view" %}} |
There was a problem hiding this comment.
I figure people would query their replacement to check. we can place this somewhere else .. but eh.
| [resizing your clusters](/sql/alter-cluster/#resizing) to a larger size before | ||
| applying the replacement. This helps ensure sufficient memory is available while | ||
| the diff is being processed, and will prevent out of memory errors. | ||
| the diff is being processed and will prevent out of memory errors. |
There was a problem hiding this comment.
I could tweak this to specific clusters ... but eh.
| the diff is being processed and will prevent out of memory errors. | ||
|
|
||
| You can resize back down after the replacement is complete. To automate this | ||
| process, you can consider using [mz-clusterctl](https://github.com/MaterializeInc/mz-clusterctl), |
There was a problem hiding this comment.
Also, just wondering ... since in the mz-clusterctl readme, we do state it's experimental.
There was a problem hiding this comment.
I think we should keep this in personally!
There was a problem hiding this comment.
👍 no objection ... more just wanted to clarify our product stance 😄
| process, you can consider using [mz-clusterctl](https://github.com/MaterializeInc/mz-clusterctl), | ||
| which will auto-scale cluster sizes based on cluster activity. | ||
|
|
||
| ### Use separate clusters for replacements |
There was a problem hiding this comment.
Per discussion in person yesterday ... we don't want to do this.
If people want to use the create replacement/apply replacement as a way to move cluster for a mv ... that will be a different use case.
| The original and replacement materialized views must have compatible schemas. | ||
| This includes having identical columns, column order, and constraints. | ||
|
|
||
| ### Transactions |
There was a problem hiding this comment.
A lot of things aren't currently supported in transactions ... so, this is no different.
|
|
||
| ## Limitations | ||
|
|
||
| ### Schema compatibility |
There was a problem hiding this comment.
Eh ... removed ... since we already mention it above and people cannot create a replacement with different schema ... as such, the original and replacement mv will have compatible schemas.
| ``` | ||
|
|
||
|
|
||
| ### Dropping a replacement |
There was a problem hiding this comment.
Moved this to best practices for unused replacement below 97c967f#diff-efce666a496656c8382f08006cb2bdcb819b9167aacd83a40876168ec95dc128R347
| -- The lowest_winning_bid should be greater than 50 | ||
| SELECT * FROM auction_house.mv_org_leaderboard | ||
| ORDER BY total_spent DESC | ||
| LIMIT 5; |
There was a problem hiding this comment.
tweaked ... since people didn't query the leaderboard before, just ordering by total_spent doesn't really verify anything.
| Once the replacement materialized view is fully hydrated, apply it. | ||
| When you apply the view, Materialize calculates the diff between the | ||
| original and the replacement. At this point, the diff is applied | ||
| to the original view, along with all downstream objects. |
|
my best friend, the linter, is unhappy - let me fix this |
|
Ok finally ready for re-review @kay-kim |
2 participants
Tutorial for replacement materialized views