Re: pg_stat_user_functions' notion of user

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_stat_user_functions' notion of user
Date: 2010-08-09 00:33:23
Message-ID: 2413.1281314003@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On sn, 2010-08-08 at 11:59 -0400, Tom Lane wrote:
>> The reason for the inconsistency is that the underlying behavior is
>> different: fmgr automatically doesn't collect stats for internal
>> functions.

> Sure it does: When they are defined in language SQL.

Those aren't "internal" (in the sense of prolang = 12) functions.

The big picture here is that we intentionally suppressed collection of
stats for "internal" functions because of performance concerns. The
test in the pg_stat_user_functions view is not about restricting what
functions can be shown in the view; it's just a small performance
optimization to avoid calling the low-level pg_stat_get_ functions for
pg_proc entries that we know a-priori won't have any stats.

If we added a clause to hide functions based on their schema, we would
logically need to provide the full set of pg_stat_all_functions,
pg_stat_sys_functions, and pg_stat_user_functions views. Otherwise the
views would provide no way to get at stats for functions that the
collection mechanism is perfectly willing to collect stats for. I'm
not convinced that it's worth the trouble, but we'd have to do it
if we decide to filter on schema as well as prolang.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-08-09 00:40:51 Re: pg_stat_user_functions' notion of user
Previous Message Robert Haas 2010-08-08 22:19:39 Re: Initial review of xslt with no limits patch