Module mz_storage_types::dyncfgs
source · Expand description
Dyncfgs used by the storage layer. Despite their name, these can be used “statically” during rendering, or dynamically within timely operators.
Constants§
- Whether rendering should use
mz_join_core
rather than DD’sJoinCore::join_core
. Configuration for basic hydration backpressure. - Whether or not to enforce that external connection addresses are global (not private or local) when resolving them.
- Rules for enriching the
client.id
property of Kafka clients with additional data. - The timeout when seeking through a consumer when fast-forwarding it. We expect this to happen quickly.
- The maximum time we will wait before re-polling rdkafka to see if new partitions/data are available.
- Interval to fetch
offset_known
, from@gtid_executed
- Replication heartbeat interval requested from the MySQL server.
- Interval to poll
confirmed_flush_lsn
to get a resumption lsn. - Interval to fetch
offset_known
, frompg_current_wal_lsn
- When enabled, force-downgrade the controller’s since handle on the shard during shard finalization.
- How many times to try to cleanup old RocksDB DB’s on disk before giving up.
- Whether to enable the merge operator in upsert for the RocksDB backend.
- If
storage_upsert_prevent_snapshot_buffering
is true, this prevents the upsert operator from buffering too many events from the upstream snapshot. In the absence of hydration flow control, this could prevent certain workloads from causing egregiously large writes to RocksDB. - Whether or not to prevent buffering the entire upstream snapshot in memory when processing it in memory. This is generally understood to reduce memory consumption.
Functions§
- Adds the full set of all storage
Config
s.