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
Concretely, currently we might report that this ran twice:
SET CLUSTER SETTING _ = _
Instead, since the settings names are hard-coded consts, we know they're non-sentiive and we can instead report that that each of these ran once:
SET CLUSTER SETTING kv.bulk_sst.sync_size = _
SET CLUSTER SETTING kv.bulk_io_write.max_rate = _
We currently scrub settings names from diagnostics collection because we just scrub all strings from the query AST, but settings names are actually taken from a relatively small set of known const strings and we an check they're valid with settings.Lookup, in which case they can be left unscrubbed, providing extra insight into what settings users need to change and how often.
This product question is already partially answered by including the set of non-default settings in diagnostics reporting -- we can already see what settings users have set and can even see that set change between report -- but if e.g. a setting was changed 20 times between reports, we'd only see the fact that it was different at the next report, not that it took several attempt to tune it or whatever.
The text was updated successfully, but these errors were encountered:
Concretely, currently we might report that this ran twice:
Instead, since the settings names are hard-coded consts, we know they're non-sentiive and we can instead report that that each of these ran once:
We currently scrub settings names from diagnostics collection because we just scrub all strings from the query AST, but settings names are actually taken from a relatively small set of known const strings and we an check they're valid with settings.Lookup, in which case they can be left unscrubbed, providing extra insight into what settings users need to change and how often.
This product question is already partially answered by including the set of non-default settings in diagnostics reporting -- we can already see what settings users have set and can even see that set change between report -- but if e.g. a setting was changed 20 times between reports, we'd only see the fact that it was different at the next report, not that it took several attempt to tune it or whatever.
The text was updated successfully, but these errors were encountered: