Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Oprofile suggests that most of the time is actually spent in
> pgstat_vacuum_stat. And more precisely in pstat_collect_oids, which is
> called by pgstat_vacuum_stat.
> We added support for tracking call counts and elapsed runtime of
> user-defined functions back in May. That added the code to
> pgstat_vacuum_stat to tell stats collector about deleted functions,
> which involves populating a hash table of all functions in the database.
> It looks like *that's* what's causing the slowdown.
> I think we can live with the extra overhead.
Hmm. It's unfortunate that someone decided to use the exact same
technology for cleaning pg_proc entries as pg_class/pg_database entries,
when the former table has an order of magnitude more entries, most of
which will certainly never change.
It might help if we ignored INTERNAL-language entries in pg_proc.
Or maybe the whole approach is wrong, since there are likely to be
far fewer active stats records for functions than for tables. In
particular we should at least try to bypass the pg_proc scan when
there are *no* function stats records.
regards, tom lane
