Summary:
Currently, we have two control gflags for auto analyze service:
(1) `ysql_enable_table_mutation_counter`: a non-runtime flag which controls the creation of table mutation count sender and enables/disables accumulating the node-level mutation counts of tables. Default: False.
(2) `ysql_enable_auto_analyze_service`: a runtime flag which on master enables/disables the creation of the auto analyze service table; on tserver enables/disables the periodic task of the auto analyze service. Default: False.
This diff simplifies the knobs into the following:
(1) `ysql_enable_auto_analyze_infra`: this is an auto flag. If set, the infra required for auto analyze service is created. The flag is true on new cluster or after all the processes in an universe have been upgraded to the new code version.
(2) `ysql_enable_auto_analyze`: a tserver runtime flag to control if one `TableMutationCountSender` sends collected mutations to auto analyze service and control the main periodic task loop of auto analyze service. Default: False
With the flag change, the node level mutation counts are always incremented and the auto analyze service main loop is controlled by new flag: `ysql_enable_auto_analyze`.
For existing clusters with running auto analyze service using old flags (i.e. `ysql_enable_table_mutation_counter` and `ysql_enable_auto_analyze_service` are both `True`), `ysql_enable_auto_analyze` value is adjusted to `True` during Tserver creation so that auto analyze keeps running after upgrade.
Upgrade safety:
(1) For a cluster with running auto analyze service using old flags, after upgrade, the new flag `ysql_enable_auto_analyze_infra` takes no effects on master because the infrastructure of auto analyze service has been created without any on-disk data format change. The new flag `ysql_enable_auto_analyze` is adjusted to `True`, and auto analyze service can start working immediately after upgrade.
(2) For a cluster which has used auto analyze service with old flags turned off (either `ysql_enable_table_mutation_counter` or `ysql_enable_auto_analyze_service` is false), after upgrade, the new flag `ysql_enable_auto_analyze_infra` takes no effects on master because the infrastructure of auto analyze service has been created without any on-disk data format change. The new flag `ysql_enable_auto_analyze` remains false, so auto analyze is not enabled after upgrade.
(3) For a cluster without enabling auto analyze service, auto analyze service will be created after all processes in the cluster have been upgraded to the new version. The user needs to enable it by setting `ysql_enable_auto_analyze` to True. This is the default behavior for most customers who haven't touched the flags.
(4) For a new cluster, the auto analyze service will be created by default. A user needs to enable it by setting `ysql_enable_auto_analyze` to True.
New flag values after upgrade based on old flags:
| | ysql_enable_auto_analyze_service | ysql_enable_table_mutation_counter | ysql_enable_auto_analyze_infra | ysql_enable_auto_analyze |
| case 1 | True | True | True | True |
| case 2.1 | True | False | True | False |
| case 2.2 | False | True | True | False |
| case 2.3 | False | False | True | False |
| case 3 | N/A|N/A | True | False |
| case 4 | N/A| N/A | True | False |
Jira: DB-13582
Test Plan:
./yb_build.sh --cxx-test pgwrapper_pg_auto_analyze-test
Manually test that new flag value `ysql_enable_auto_analyze` is adjusted based on `ysql_enable_auto_analyze_service` and `ysql_enable_table_mutation_counter`.
Reviewers: mihnea, hsunder, pjain, sanketh
Reviewed By: hsunder, sanketh
Subscribers: sanketh, hsunder, ybase, yql
Tags: #jenkins-ready
Differential Revision: https://phorge.dev.yugabyte.com/D39314
