Details
-
New Feature
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
Description
max_recursive_iterations limits the amount of iterations, but currently it is not possible
to monitor the current amount of iteration to estimate a reasonable limit.
I suggest to introduce 3 new status variables on global and session base.
recursive_iterations_avg
- average amount of iterations of all recursive cte statements.
recursive_iterations_max
- highest amount of iterations of all recursive cte statements.
recursive_iterations_reached_max
- how often the max_recursive_iterations limit was reached
Attachments
Activity
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?
So feature request more or less changed to
log CTEss, which reached max_recursive_iterations ?
With MDEV-7389 - the warnings can be logged to the SQL_ERROR_LOG plugin.
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