Procedure calls are not tracked in pg_stat_user_functions / track_functions
Hi all,
It seems that currently procedures do not get tracked when track_functions
is enabled, which means one needs to resort to other workarounds in order
to monitor procedure calls/runtime.
To illustrate:
=# SHOW track_functions;
┌─────────────────┐
│ track_functions │
├─────────────────┤
│ all │
└─────────────────┘
(1 row)
=# CALL abc();
CALL
=# SELECT def();
┌─────┐
│ def │
├─────┤
│ │
└─────┘
(1 row)
=# SELECT * FROM pg_stat_user_functions;
┌─[ RECORD 1 ]────────────────────┐
│ funcid │ 75223 │
│ schemaname │ public │
│ funcname │ def │
│ calls │ 1 │
│ total_time │ 3.222 │
│ self_time │ 3.222 │
└────────────┴────────────────────┘
Was this intentional, or an oversight?
If welcome, I would be happy to work on a patch. Whilst slightly confusing
in terms of naming, we could just track this together with functions, since
one can always join with pg_proc to determine whether something is a
function or a procedure.
Thanks,
Lukas
--
Lukas Fittl
Hi,
On 2018-10-04 12:15:28 -0700, Lukas Fittl wrote:
Hi all,
It seems that currently procedures do not get tracked when track_functions
is enabled, which means one needs to resort to other workarounds in order
to monitor procedure calls/runtime.To illustrate:
=# SHOW track_functions;
┌─────────────────┐
│ track_functions │
├─────────────────┤
│ all │
└─────────────────┘
(1 row)=# CALL abc();
CALL=# SELECT def();
┌─────┐
│ def │
├─────┤
│ │
└─────┘
(1 row)=# SELECT * FROM pg_stat_user_functions;
┌─[ RECORD 1 ]────────────────────┐
│ funcid │ 75223 │
│ schemaname │ public │
│ funcname │ def │
│ calls │ 1 │
│ total_time │ 3.222 │
│ self_time │ 3.222 │
└────────────┴────────────────────┘Was this intentional, or an oversight?
If welcome, I would be happy to work on a patch. Whilst slightly confusing
in terms of naming, we could just track this together with functions, since
one can always join with pg_proc to determine whether something is a
function or a procedure.
Yea, that sounds wrong / not ideal to me. I think we should just fix
this, should be easy enough.
- Andres
On 04/10/2018 22:07, Andres Freund wrote:
On 2018-10-04 12:15:28 -0700, Lukas Fittl wrote:
Was this intentional, or an oversight?
If welcome, I would be happy to work on a patch. Whilst slightly confusing
in terms of naming, we could just track this together with functions, since
one can always join with pg_proc to determine whether something is a
function or a procedure.Yea, that sounds wrong / not ideal to me. I think we should just fix
this, should be easy enough.
Here is a patch.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Track-procedure-calls-in-pg_stat_user_functions.patchtext/plain; charset=UTF-8; name=0001-Track-procedure-calls-in-pg_stat_user_functions.patch; x-mac-creator=0; x-mac-type=0Download
From 4f9e88e68ef5b29d91830b33306752dba1d25e0a Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Fri, 5 Oct 2018 14:14:03 +0200
Subject: [PATCH] Track procedure calls in pg_stat_user_functions
---
src/backend/commands/functioncmds.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/backend/commands/functioncmds.c b/src/backend/commands/functioncmds.c
index 68109bfda0..80ad3c770a 100644
--- a/src/backend/commands/functioncmds.c
+++ b/src/backend/commands/functioncmds.c
@@ -60,6 +60,7 @@
#include "parser/parse_expr.h"
#include "parser/parse_func.h"
#include "parser/parse_type.h"
+#include "pgstat.h"
#include "utils/acl.h"
#include "utils/builtins.h"
#include "utils/fmgroids.h"
@@ -2219,6 +2220,7 @@ ExecuteCallStmt(CallStmt *stmt, ParamListInfo params, bool atomic, DestReceiver
EState *estate;
ExprContext *econtext;
HeapTuple tp;
+ PgStat_FunctionCallUsage fcusage;
Datum retval;
fexpr = stmt->funcexpr;
@@ -2302,7 +2304,9 @@ ExecuteCallStmt(CallStmt *stmt, ParamListInfo params, bool atomic, DestReceiver
i++;
}
+ pgstat_init_function_usage(&fcinfo, &fcusage);
retval = FunctionCallInvoke(&fcinfo);
+ pgstat_end_function_usage(&fcusage, true);
if (fexpr->funcresulttype == VOIDOID)
{
base-commit: ff347f8aff04865680c19ffc818460bb2afaad5b
--
2.19.0
On 05/10/2018 14:15, Peter Eisentraut wrote:
On 04/10/2018 22:07, Andres Freund wrote:
On 2018-10-04 12:15:28 -0700, Lukas Fittl wrote:
Was this intentional, or an oversight?
If welcome, I would be happy to work on a patch. Whilst slightly confusing
in terms of naming, we could just track this together with functions, since
one can always join with pg_proc to determine whether something is a
function or a procedure.Yea, that sounds wrong / not ideal to me. I think we should just fix
this, should be easy enough.Here is a patch.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services