# `VERSION::7.5.0` Controlling the Statistics Initial Load Behavior - Example

+ Server 3 and 4 can not provide service yet.

![`smart`](LoadStatistics02_aa_002_20231225.png)

------------------------------------------------------------------------------
Consider a scenario with four TiDB server instances, each configured with distinct combinations of the `performance.force-init-stats` and `performance.lite-init-stats` parameters.

TiDB Server 1 and TiDB Server 2 are configured with the `performance.force-init-stats` parameter set to `false`, enabling them to provide services even if the statistics loading process is incomplete. Conversely, TiDB Server 3 and TiDB Server 4 are required to wait until the statistics loading process completes before they can begin service provision, as their `performance.force-init-stats` parameter is set to `true`.

The feature of lightweight statistics initialization is activated in TiDB Server 1 and TiDB Server 3, as indicated by the `performance.lite-init-stats` parameter being set to `true`. This setup necessitates only the loading of basic statistical data such as count, distinctCount, and nullCount to fulfill the statistics initialization requirements. In contrast, TiDB Server 2 and TiDB Server 4 have this feature disabled, with `performance.lite-init-stats` set to `false`. Consequently, both basic statistics and detailed statistical data, including histograms, TopN, and Count-Min Sketch for indexes and primary keys, are loaded into memory.

Among these configurations, TiDB Server 4 loads the most comprehensive set of statistics after startup, resulting in the slowest initiation of services.

Notes:
1. Histograms, TopN, and Count-Min Sketch data for non-primary key columns are not pre-loaded in any of these configurations. Such data are loaded into memory only when SQL statements query the corresponding columns.
2. Due to the ongoing statistics loading or the use of outdated statistical information, TiDB Server 1 and TiDB Server 2 may experience execution plan variations during SQL queries. The presence of a `pseudo` tag in the operator info section of an execution plan can be verified using the output of the `EXPLAIN` command.