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
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 |