Hi,

pg_stat_statements module distinguishes queries with different structures, but some visibly different MERGE queries were combined as one pg_stat_statements entry.
For example,
MERGE INTO test1 USING test2 ON test1.id = test2.id WHEN MATCHED THEN UPDATE var = 1; MERGE INTO test1 USING test2 ON test1.id = test2.id WHEN MATCHED THEN DELETE; These two queries have different command types after WHEN (UPDATE and DELETE), but they were regarded as one entry in pg_stat_statements.
I think that they should be sampled as distinct queries.

I attached a patch file that adds information about MERGE queries on the documentation of pg_stat_statements, and lines of code that helps with the calculation of queryid hash value to differentiate MERGE queries.
Any kind of feedback is appreciated.

Tatsu
diff --git a/doc/src/sgml/pgstatstatements.sgml b/doc/src/sgml/pgstatstatements.sgml
index ecf6cd6bf3..ea90365c7f 100644
--- a/doc/src/sgml/pgstatstatements.sgml
+++ b/doc/src/sgml/pgstatstatements.sgml
@@ -487,7 +487,7 @@
 
   <para>
    Plannable queries (that is, <command>SELECT</command>, <command>INSERT</command>,
-   <command>UPDATE</command>, and <command>DELETE</command>) are combined into a single
+   <command>UPDATE</command>, <command>DELETE</command>, and <command>MERGE</command>) are combined into a single
    <structname>pg_stat_statements</structname> entry whenever they have identical query
    structures according to an internal hash calculation.  Typically, two
    queries will be considered the same for this purpose if they are
@@ -783,7 +783,7 @@
       <varname>pg_stat_statements.track_utility</varname> controls whether
       utility commands are tracked by the module.  Utility commands are
       all those other than <command>SELECT</command>, <command>INSERT</command>,
-      <command>UPDATE</command> and <command>DELETE</command>.
+      <command>UPDATE</command>, <command>DELETE</command>, and <command>MERGE</command>.
       The default value is <literal>on</literal>.
       Only superusers can change this setting.
      </para>
diff --git a/src/backend/utils/misc/queryjumble.c b/src/backend/utils/misc/queryjumble.c
index a67487e5fe..6417f6e868 100644
--- a/src/backend/utils/misc/queryjumble.c
+++ b/src/backend/utils/misc/queryjumble.c
@@ -257,6 +257,7 @@ JumbleQueryInternal(JumbleState *jstate, Query *query)
 	JumbleExpr(jstate, (Node *) query->windowClause);
 	JumbleExpr(jstate, (Node *) query->distinctClause);
 	JumbleExpr(jstate, (Node *) query->sortClause);
+	JumbleExpr(jstate, (Node *) query->mergeActionList);
 	JumbleExpr(jstate, query->limitOffset);
 	JumbleExpr(jstate, query->limitCount);
 	APP_JUMB(query->limitOption);
@@ -823,6 +824,15 @@ JumbleExpr(JumbleState *jstate, Node *node)
 				JumbleExpr(jstate, (Node *) tsc->repeatable);
 			}
 			break;
+		case T_MergeAction:
+			{
+				MergeAction *mergeaction = (MergeAction *) node;
+
+				APP_JUMB(mergeaction->commandType);
+				JumbleExpr(jstate, mergeaction->qual);
+				JumbleExpr(jstate, (Node *) mergeaction->targetList);
+			}
+			break;
 		default:
 			/* Only a warning, since we can stumble along anyway */
 			elog(WARNING, "unrecognized node type: %d",


Reply via email to