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
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Ralf Gebhardt [ ralf.gebhardt@mariadb.com ] |
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?
| 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 |
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 |
So feature request more or less changed to
log CTEss, which reached max_recursive_iterations ?
| Issue Type | Task [ 3 ] | New Feature [ 2 ] |
| Assignee | Ralf Gebhardt [ ralf.gebhardt@mariadb.com ] | Richard Stracke [ richard ] |
| Status | Open [ 1 ] | Needs Feedback [ 10501 ] |
| Assignee | Richard Stracke [ richard ] | Ralf Gebhardt [ ralf.gebhardt@mariadb.com ] |
| Status | Needs Feedback [ 10501 ] | Open [ 1 ] |
With MDEV-7389 - the warnings can be logged to the SQL_ERROR_LOG plugin.
| Zendesk Related Tickets | 141457 |
| Assignee | Ralf Gebhardt [ ralf.gebhardt@mariadb.com ] | Michael Widenius [ monty ] |
| Labels | CTE status | CTE beginner-friendly status |
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