Skip to content

Conversation

@antiguru
Copy link
Member

@antiguru antiguru commented Feb 6, 2025

Some ideas around categorizing a workload as production-ready.

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.

Signed-off-by: Moritz Hoffmann <mh@materialize.com>
@antiguru
Copy link
Member Author

Add an alternative where we allow only indexes that are simple dataflows.

Comment on lines +89 to +95
### Observing the workload status

A replica receives a stream of commands, which includes punctuation to distinguish a prefix of re-applied operations from updates in steady-state.
We could lean into this to determine whether a replica has observed DDL since it entered steady-state.
A replica that has not observed DDL is considered clean, versus one that has observed DDL, which is considered dirty.

In this context, all instructions to render dataflows, or advance frontiers to the empty frontier, are considered replica-level DDL.
Copy link
Contributor

Choose a reason for hiding this comment

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

+1. This seems like a great signal.

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