[MDEV-19574] innodb_stats_method is not honored when innodb_stats_persistent=ON Created: 2019-05-23 Updated: 2023-11-28 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.3.15 |
| Fix Version/s: | 10.6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Sergei Petrunia | Assignee: | Thirunarayanan Balathandayuthapani |
| Resolution: | Unresolved | Votes: | 3 |
| Labels: | upstream | ||
| Issue Links: |
|
||||||||
| Description |
|
The value of innodb_stats_method is not honored when innodb_stats_persistent=ON. Steps to reproduce:
Now, let's see what we've got:
Cardinality(a)=253K. There are actually 101K different values, but this is an estimate, so I'm fine with this value (for this MDEV at least). Now, let's treat all NULLs as unequal, which means 'a' will have 500K different values:
Cardinality(a)=498K. Good - same as PK, close to reality. Now, let's try to repeat the above steps with persistent statistics.
Cardinality(a)=250K. Close to what we've got for non-persistent stats, ok.
Still, Cardinality(a)=250K! Now, this is NOT acceptable. |
| Comments |
| Comment by Sergei Petrunia [ 2019-05-23 ] |
|
Looking at InnoDB code: innodb_stats_method is called srv_innodb_stats_method uses of this variable: dict_index_t has
I dont see any provisions to store these two arrays in persistent stats, though. |
| Comment by Sergei Petrunia [ 2019-05-23 ] |
|
Reproducible on MySQL 8.0.16 (current latest) : https://gist.github.com/spetrunia/67c83d21faf925a2be3a48383084ab6f |
| Comment by Valerii Kravchuk [ 2019-05-23 ] |
|
Does it make sense to report upstream MySQL bug? |
| Comment by Sergei Petrunia [ 2019-05-23 ] |
| Comment by Sergei Petrunia [ 2019-05-23 ] |
|
A better paste showing it being reproduced on MySQL 8.0: https://gist.github.com/spetrunia/7be5a577f46635b7f254c2ed70e50332 |
| Comment by Hans Kristian Rosbach [ 2019-09-05 ] |
|
This issue is linked from MDEV-17295 |
| Comment by Marko Mäkelä [ 2022-08-02 ] |
|
psergei, thank you for the analysis. Another quick observation is that null pointer checks are duplicated both at the start of btr_record_not_null_field_in_rec() and before its calls in btr_estimate_number_of_different_key_vals(). In the elements of the vector that is returned by btr_estimate_number_of_different_key_vals(), there are index_field_stats_t::n_non_null_key_vals that will be copied to dict_index_t::stat_n_non_null_key_vals in dict_stats_update_persistent(). But, that data field will be skipped by dict_stats_save() and set to 0 in dict_stats_fetch_index_stats_step(). In A minimal data format change to implement this fix would seem to be to introduce mysql.innodb_index_stats.stat_name keys similar to n_diff_pfx%02u, for persisting the index_field_stats_t::n_non_null_key_vals. While file format changes are something that should be avoided in GA versions, maybe we could make an exception here. At least starting with 10.6, dict_stats_delete_from_index_stats() would drop all statistics for a being-dropped table, for any stat_name. thiru, can you implement the following?
I think that this should target the 10.6 series, because before |