-
-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recursive plan output for queries involving selectable stored procedures #7709
base: master
Are you sure you want to change the base?
Conversation
|
I would prefer the session environment statement. So that you do not have to do reconnections. |
Does you considered to show plan of separate PSQL objects as separate entities ?
|
Taking into account that stored routines cannot have variable plans and show plans for all routes, there is no point to output plan for any function more than once. |
Forgot to add - it will have big effect (readability and text size) when SP2 calls SP1 many times |
I'm afraid they will not affect plan depth inside MON$ tables, because plans are dumped by other attachments that may see different value of the max plan depth. Would it be OK if the session override will not affect MON$ tables (they will use config setting)? |
From one side, I like this - because the truncation at the 64KB limit is likely to happen after then main plan, while in my implementation it may happen in the middle of the main plan. Also I agree with @aafemt that it does not make sense to print the same routine multiple times. From another side, it makes impossible to track who calls who, which is quite straightforward in my output. |
Maybe this setting shouldn't affect the plans in mon$? We have mon$compiled_statement, which allows you to detail procedure plans. |
May be I didn't get your point, but at the sample above it is clear that:
|
Yeah, you're right. I need to think more about this. |
In such a conclusion of the plan, there is a question in what order the procedure plans should be printed. Depth or width traversal? |
Width, i.e. first should be printed the objects that referenced directly by the query (i.e. at 1st level), than objects that referenced by the just printed objects, and so on. Honestly, I see no real need to use more than 1 level of references. In the sample above, it will not print plan of P1. |
This forces a user to perform such recursion or implements a tool. An example could be comparing or monitoring plans during time or after upgrade using trace for example. |
This case seems broken:
|
What about |
Related to issue #5322.
Prior to v3.0, if the query includes selectable procedures, their plans were embedded into the main query plan. This was changed in v3 due to refactoring and because such "mixed" plans were often hardly readable. But users kept complaining the feature was useful, at least to analyze plans for possible NATURAL scans inside. I'm still pessimistic about that, but the explained plan format allows to show embedded plans nicely indented, so why not. This PR re-allows embedding nested plans into the main one. It's controlled by the configuration parameter and disabled by default (thus compatible with v3 and v4).
Example:
Questions:
PlanRecursionLimit
parameter name OK or should it be better namedMaxPlanRecursion
?