Re: pg_stat_user_functions' notion of user

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_stat_user_functions' notion of user
Дата
Msg-id 2413.1281314003@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_stat_user_functions' notion of user  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Initial review of xslt with no limits patch
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: pg_stat_user_functions' notion of user