You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adds the durable table that hydration episodes are recorded into. Nothing writes
it yet, the collector arrives separately.
The table is in `mz_internal` because its contents are best effort and its
`status` column will gain values as more hydration events become observable. An
episode is identified by `(object_id, replica_id, installed_at)`, using the
replica-stamped installation time because it is stable across an environmentd
restart. That identity is not declared as a key on the relation: the collector's
anti-join is what keeps it unique, and telling the optimizer a best-effort
sampler's output is unique would turn any duplicate into a silently wrong query
result. None of the comparable history tables declare one either.
No index. An arrangement on the catalog server would hold the whole table, which
grows with objects times replicas times re-hydrations, and nothing queries this
table by key yet.
NOTE: Adding one later is not only an index. `make_mz_indexes` inlines the
builtin index set as VALUES, so a new index changes the `mz_indexes` fingerprint
and needs a `MigrationStep::replacement` for it pinned to the then-current dev
version. A step at a stale version is skipped and the fingerprint check panics at
catalog open.
Contents are exempt from the bootstrap reset and from forced schema migrations,
since a sampled history cannot be rebuilt from anything else once it is gone.
Durability is best effort in both directions, and the assert added here is a
tripwire so that clearing the table is chosen rather than stumbled into.
Ref: SQL-644
Copy file name to clipboardExpand all lines: doc/user/content/reference/system-catalog/mz_internal.md
+22Lines changed: 22 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -704,6 +704,28 @@ The `mz_object_history` view enriches the [`mz_catalog.mz_objects`](/reference/s
704
704
|`created_at`|[`timestamp with time zone`]| Wall-clock timestamp of when the object was created. `NULL` for built in system objects. |
705
705
|`dropped_at`|[`timestamp with time zone`]| Wall-clock timestamp of when the object was dropped. `NULL` for built in system objects or if the object hasn't been dropped. |
706
706
707
+
## `mz_object_hydration_history`
708
+
709
+
The `mz_object_hydration_history` table records completed hydration of indexes and
710
+
materialized views, with one row for each time an object hydrated on a replica. Rows
711
+
are retained for 30 days, and `object_id`, `cluster_id`, and `replica_id` may name
712
+
objects that no longer exist.
713
+
714
+
Recording is best effort. Only successful hydration is recorded, an episode can be
715
+
missed if the object or its replica goes away before the episode is recorded, and a
716
+
schema change to this table in a future release may clear its contents.
|`object_id`|[`text`]| The ID of the index or materialized view. May name an object that no longer exists. |
722
+
|`cluster_id`|[`text`]| The ID of the object's cluster. |
723
+
|`replica_id`|[`text`]| The ID of the cluster replica. May name a replica that no longer exists. |
724
+
|`installed_at`|[`timestamp with time zone`]| When the object's dataflow was installed on the replica. |
725
+
|`started_at`|[`timestamp with time zone`]| When hydration work began, or `NULL` if the replica reported none. A replica that observed no start reports the installation time instead, so a zero interval between the two does not mean the dataflow started immediately. |
726
+
|`finished_at`|[`timestamp with time zone`]| When hydration finished. |
727
+
|`status`|[`text`]| The terminal status. Currently always `hydrated`. |
728
+
707
729
## `mz_object_transitive_dependencies`
708
730
709
731
The `mz_object_transitive_dependencies` view describes the transitive dependency structure between
"The ID of the index or materialized view. May name an object that no longer exists.",
5060
+
),
5061
+
("cluster_id","The ID of the object's cluster."),
5062
+
(
5063
+
"replica_id",
5064
+
"The ID of the cluster replica. May name a replica that no longer exists.",
5065
+
),
5066
+
(
5067
+
"installed_at",
5068
+
"When the object's dataflow was installed on the replica.",
5069
+
),
5070
+
(
5071
+
"started_at",
5072
+
"When hydration work began, or `NULL` if the replica reported none. A replica that observed no start reports the installation time instead, so a zero interval between the two does not mean the dataflow started immediately.",
5073
+
),
5074
+
("finished_at","When hydration finished."),
5075
+
(
5076
+
"status",
5077
+
"The terminal status. Currently always `hydrated`.",
5078
+
),
5079
+
]),
5080
+
// Not a retained-metrics object: that would pin a 30 day compaction window,
5081
+
// and our history lives in the rows, which the retention sweep retracts on
5082
+
// its own schedule. Nothing reads this table at an old timestamp.
5083
+
is_retained_metrics_object:false,
5084
+
access:vec![PUBLIC_SELECT],
5085
+
ontology:Some(Ontology{
5086
+
entity_name:"object_hydration_event",
5087
+
description:"Completed hydration of an index or materialized view on a replica",
5088
+
// NOTE: These references outlive what they point at. A row deliberately
5089
+
// survives the object and the replica it describes, so resolving one
0 commit comments