[MDEV-30754] introduce monitoring status variables for max_recursive_iterations Created: 2023-02-28 Updated: 2023-11-30 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Optimizer - CTE |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major |
| Reporter: | Richard Stracke | Assignee: | Ralf Gebhardt |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | CTE, status | ||
| Description |
|
max_recursive_iterations limits the amount of iterations, but currently it is not possible I suggest to introduce 3 new status variables on global and session base. recursive_iterations_avg
recursive_iterations_max
recursive_iterations_reached_max
|
| Comments |
| Comment by Sergei Golubchik [ 2023-03-28 ] |
|
I don't think this makes a lot of sense. The "average" value is particularly meaningless, the application might use many different CTE's the average recursion depth is not helpful at all. how many times the max_recursive_iterations limit was reached is better, but to be really useful it should also tell what CTE has reached this limit. And we cannot put it in a status variable. May be the server should push a note when this happens? Not that it'll help much |
| Comment by Ralf Gebhardt [ 2023-05-03 ] |
|
serg, wouldn't it make more sense to use the slow query log to log CTEs, which reached max_recursive_iterations ? Or would the performance schema be a better place? As these would only be activated to track down issues, a status variable for how many times the max_recursive_iterations was reached would make sense for a general monitoring, before looking into the details. Doesn't the client get a warning when executing a CTE, which is reaching max_recursive_iterations? |
| Comment by Sergei Golubchik [ 2023-05-03 ] |
|
slow log kinda makes sense, I agree |
| Comment by Richard Stracke [ 2023-11-07 ] |
|
So feature request more or less changed to |