Performance: only plan the dynamic severity branches when they are used - #3081
Open
TheBeast85 wants to merge 1 commit into
Open
Performance: only plan the dynamic severity branches when they are used#3081TheBeast85 wants to merge 1 commit into
TheBeast85 wants to merge 1 commit into
Conversation
report_severity was one function body, and that body was planned again on every call. Measured on the severity aggregate with pg_stat_statements.track_planning on, that was 1479 ms of planning across 5047 calls against 30 ms of execution. Marking it STABLE and taking out its CTE did not help: task_severity calls report_severity from its own SQL body and task_severity is itself not inlinable, its body has a subquery with FROM, so every row creates a fresh call context. What costs the planning is not the common case. Almost every call is answered by the cached value in report_counts, a single index lookup, while the four dynamic branches underneath scan the results table and are hardly ever evaluated. A function body is only planned when the function is invoked, and coalesce stops at the first non null argument at execution time. Split into report_severity_cached, report_severity_dynamic and a report_severity that is a coalesce of the two, the expensive body is no longer planned at all; it stops appearing in pg_stat_statements. The severity functions are marked STABLE, which is also what lets report_severity be inlined. The severity aggregate goes from 0.351 s to 0.098 s. Severity values and the aggregate are identical character for character with the reference taken before the change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
report_severityintoreport_severity_cached,report_severity_dynamicand areport_severitythat is acoalesceof the two.STABLE.Why
report_severitywas one function body, and that body was planned again on every call: 1479 ms of planning across 5047 calls against 30 ms of execution, measured on the severity aggregate withpg_stat_statements.track_planningon.Almost every call is answered by the cached value in
report_counts, a single index lookup. The four dynamic branches underneath scan theresultstable and are hardly ever evaluated, yet every call paid to plan them. A function body is only planned when the function is invoked, andcoalescestops at the first non null argument at execution time, so moving the expensive branches into their own function means they are only planned when there is no cached value. They stop appearing inpg_stat_statementsaltogether.STABLEalone did not help, and neither did removing the CTE:task_severitycallsreport_severityfrom its own SQL body and is itself not inlinable, so every row creates a fresh call context.The severity aggregate goes from 0.351 s to 0.098 s. Severity values and the aggregate are identical character for character with the reference taken before the change.
References
Split out of #3067 as requested.
Checklist