Re: pg_stat_user_functions' notion of user - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_stat_user_functions' notion of user
Date
Msg-id 2413.1281314003@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_stat_user_functions' notion of user  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> On sön, 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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Initial review of xslt with no limits patch
Next
From: Josh Berkus
Date:
Subject: Re: pg_stat_user_functions' notion of user