[MDEV-23640] Versioned InnoDB table doesn't auto-create partitions in time due to imprecise statistics Created: 2020-03-24 Updated: 2021-04-23 Resolved: 2021-04-23 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB, Versioned Tables |
| Affects Version/s: | N/A |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Minor |
| Reporter: | Elena Stepanova | Assignee: | Aleksey Midenkov |
| Resolution: | Not a Bug | Votes: | 0 |
| Labels: | None | ||
| Environment: |
bb-10.6-midenok- |
||
| Issue Links: |
|
||||||||
| Description |
|
I am not sure if anything can be done about it, possibly it will just have to be documented as a limitation. In this case, please add "Documentation" to the component and reassign to the documentation team. For InnoDB tables, intermediate statistics are often incorrect. Apparently, partition auto-creation (for LIMIT-based partitioning) relies on these statistics. It can cause regular and partition overflow, especially in busy environments. In the example below, LIMIT is 1000 rows, and each UPDATE updates 1500 rows. It means at least one new partition is expected to be created upon each upgrade (as I understand, the current logic can only create one, even if the update is larger than the limit). However, even that isn't happening. Since the values are non-deterministic, they can differ upon different executions, but the problem itself should still be visible.
Please also note there are no warnings at any point. |
| Comments |
| Comment by Aleksey Midenkov [ 2021-04-23 ] |
|
By design we cannot guarantee hard limit. This was reflected in |