I've noticed that in pg_stat_statements, stored procedures are almost always given a unique query id unless the query is textually identical. pg_stat_statements.c makes this pretty clear as procedures are considered utility statements and no normalization analysis is done against them. Client side invoked statements appear to be able to be parameterized so that they might be normalized correctly, but AFAICT there is no way to do this from the server or any non-parameterizing client (say, dblink).
Suffice it to say, pg_stat_statements is an administrator's dream and heavily procedure wrapped databases might struggle to generate useful statistics leading to lack of insight.
From pg_stat_statements.c in ProcessUtility():
/* * Force utility statements to get queryId zero. We do this even in cases * where the statement contains an optimizable statement for which a * queryId could be derived (such as EXPLAIN or DECLARE CURSOR). For such * cases, runtime control will first go through ProcessUtility and then * the executor, and we don't want the executor hooks to do anything, * since we are already measuring the statement's costs at the utility * level. * * Note that this is only done if pg_stat_statements is enabled and * configured to track utility statements, in the unlikely possibility * that user configured another extension to handle utility statements * only. */
Can this simply be disabled for stored procedures as a special case? I'm hoping this might do something useful that is also safe. Curious if anyone has any thoughts on this.
