Обсуждение: Procedure calls are not tracked in pg_stat_user_functions / track_functions

Поиск
Список
Период
Сортировка

Procedure calls are not tracked in pg_stat_user_functions / track_functions

От
Lukas Fittl
Дата:
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

Re: Procedure calls are not tracked in pg_stat_user_functions /track_functions

От
Andres Freund
Дата:
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


Re: Procedure calls are not tracked in pg_stat_user_functions /track_functions

От
Peter Eisentraut
Дата:
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

Вложения

Re: Procedure calls are not tracked in pg_stat_user_functions /track_functions

От
Peter Eisentraut
Дата:
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