Open teskje opened 2 months ago
One reason why we shouldn't do this is that it makes operator hydration introspection depend on per-replica introspection, with all the usability and availability issues that entails. The operator hydration logging was introduced to fuel hydration progress tracking in the console, and one design decision was specifically to not require replica-targeted queries to retrieve that information.
The compute introspection sources (in particular
mz_dataflow_operator_reachability
and the various ones describing dataflow structure) provide almost enough information to compute per-operator frontiers. The only thing missing are intra-operator summaries, which can be approximated by assuming full connectivity for all non-feedback operators, or added by additional logging in Timely. We should consider replacing the current approach of rendering dedicated operators to learn about operator hydration with a WMR view that utilizes our existing logging.Slack discussion.