Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit566a1d4

Browse files
committed
Improve contrib/pg_stat_statements' handling of PREPARE/EXECUTE statements.
It's actually more useful for the module to ignore these. IgnoringEXECUTE (and not incrementing the nesting level) allows the executorhooks to charge the time to the underlying prepared query, whichshows up as a stats entry with the original PREPARE as query string(possibly modified by suppression of constants, which might not beterribly useful here but it's not worth avoiding). This is much moreuseful than cluttering the stats table with a distinct entry for eachtextually distinct EXECUTE.Experimentation with this idea shows that it's also preferable to ignorePREPARE. If we don't, we get two stats table entries, one with the querystring hash and one with the jumble-derived hash, but with the same visiblequery string (modulo those constants). This is confusing and not veryhelpful, since the first entry will only receive costs associated withinitial planning of the query, which is not something counted at allnormally by pg_stat_statements. (And if we do start tracking planningcosts, we'd want them blamed on the other hash table entry anyway.)
1 parente0e4ebe commit566a1d4

File tree

1 file changed

+17
-2
lines changed

1 file changed

+17
-2
lines changed

‎contrib/pg_stat_statements/pg_stat_statements.c

Lines changed: 17 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -174,7 +174,7 @@ typedef struct pgssJumbleState
174174

175175
/*---- Local variables ----*/
176176

177-
/* Current nesting depth of ExecutorRun calls */
177+
/* Current nesting depth of ExecutorRun+ProcessUtility calls */
178178
staticintnested_level=0;
179179

180180
/* Saved hook values in case of unload */
@@ -773,7 +773,22 @@ pgss_ProcessUtility(Node *parsetree, const char *queryString,
773773
ParamListInfoparams,boolisTopLevel,
774774
DestReceiver*dest,char*completionTag)
775775
{
776-
if (pgss_track_utility&&pgss_enabled())
776+
/*
777+
* If it's an EXECUTE statement, we don't track it and don't increment
778+
* the nesting level. This allows the cycles to be charged to the
779+
* underlying PREPARE instead (by the Executor hooks), which is much more
780+
* useful.
781+
*
782+
* We also don't track execution of PREPARE. If we did, we would get one
783+
* hash table entry for the PREPARE (with hash calculated from the query
784+
* string), and then a different one with the same query string (but hash
785+
* calculated from the query tree) would be used to accumulate costs of
786+
* ensuing EXECUTEs. This would be confusing, and inconsistent with other
787+
* cases where planning time is not included at all.
788+
*/
789+
if (pgss_track_utility&&pgss_enabled()&&
790+
!IsA(parsetree,ExecuteStmt)&&
791+
!IsA(parsetree,PrepareStmt))
777792
{
778793
instr_timestart;
779794
instr_timeduration;

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp