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
149975: changefeedccl: emit warning when `resolved` or `min_checkpoint_frequency` is set too low r=asg0451 a=Peter-Fayez95
This change adds client-side notices to `CREATE CHANGEFEED` and `ALTER CHANGEFEED` statements when the `resolved` or `min_checkpoint_frequency` options are set below a recommended threshold (e.g., 500ms). These warnings aim to guide users toward more balanced configurations.
Setting these options too low can significantly increase CPU usage due to more frequent checkpointing and resolved timestamp emissions, introducing performance trade-offs.
Epic: CRDB-52074Fixes#149238
Release note (general change): A warning is now emitted when creating or altering a changefeed with `resolved` or `min_checkpoint_frequency` set below 500ms. This helps users understand the tradeoff between message latency and cluster CPU usage.
150146: vecindex: fix Cosine/InnerProduct accuracy bugs r=drewkimball a=andy-kimball
#### cspann: use correct metric for assigning vectors during split
Previously, during split the BalancedKmeans class was not initialized with
the distance metric used by the index. This caused vectors to be assigned
to partitions using a potentially incorrect metric, which can negatively
impact accuracy.
#### quantize: set zero dot product for centroid data vector
Previously, the dot product between a data unit vector and its quantized
form was not being set in the case where the data vector is equal to the
centroid. This could cause an issue when a RaBitQuantizedSet is reused
and the dot product memory is not zero. Fix this buglet and update the
code to scribble undefined memory.
#### quantize: recompute norm when centroid is updated
When RaBitQuantizedVectorSet.Clear was called with a new centroid, the norm
was not being recomputed. This commit fixes that bug.
150147: roachtest: actually fail TPCC bench if reached max warehouses r=miraradeva a=miraradeva
In 1bfe55b, we attempted to fail the TPCC bench test run if the configured maximum warehouses were reached and the success criteria were met. The idea was that this would prompt us to increase the max warehouses. However, that commit failed only the specific line search run, not the full test run.
This commit moves the max warehouses check out of the result handling and actually fatals the test.
Part of: #148235
Release note: None
Co-authored-by: Peter <[email protected]>
Co-authored-by: Andrew Kimball <[email protected]>
Co-authored-by: Mira Radeva <[email protected]>
testFeed:=feed(t, f, `CREATE CHANGEFEED FOR ☃ INTO 'kafka://does.not.matter/' WITH resolved='20ms'`)
5110
+
testFeed:=feed(t, f, `CREATE CHANGEFEED FOR ☃ INTO 'kafka://does.not.matter/' WITH resolved='5s'`)
5107
5111
defercloseFeed(t, testFeed)
5108
-
// Note: default min_checkpoint_frequency is set to 100ms in startTestCluster.
5109
-
require.Equal(t, `resolved (20ms) messages will not be emitted more frequently than the default min_checkpoint_frequency (100ms), but may be emitted less frequently`, actual)
5112
+
require.Equal(t, `resolved (5s) messages will not be emitted more frequently than the default min_checkpoint_frequency (30s), but may be emitted less frequently`, actual)
0 commit comments