track_functions

track_functions — Collects function-level statistics on database activity. Observed in PG9.0–19 Beta 3; its last measured boot default is none in PG19 Beta 3, with superuser context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Collects function-level statistics on database activity.”

Identity

Type , Valueenum: Upstream pg_settings type
Context , Valuesuperuser: Settable at runtime by a superuser
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Valuenone, pl, all: — for non-enum types
Category , ValueStatistics / Cumulative Query and Index Statistics: Upstream classification
Latest boot value , Valuenone: none

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–19 Beta 3
Removed in	No
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG9.0–19 Beta 3	`none`	—	none

How it works

track_functions counts calls and execution time for procedural functions with pl, and also SQL/C functions with all. none disables function-level cumulative statistics.

Simple SQL-language functions that the planner inlines disappear into the caller and are not tracked regardless of this setting. Nested function time is reported through the statistics system’s own total/self accounting.

all broadens instrumentation and can add overhead on function-heavy workloads. The counters are cumulative and observed through pg_stat_user_functions or related views. Its superuser context permits an authorized session change without a server restart.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
OLTP	Keep none unless function-level call counts and timing answer a concrete production question. Use pl to limit instrumentation to procedural languages, or all only after measuring overhead on function-heavy traffic.
OLAP	Enable pl or all for a bounded analysis when time inside functions must be separated from caller time. Remember that simple SQL functions may be inlined and remain invisible, so absence from the view is not proof of no execution.
Small nodes	Prefer none or a short scoped diagnostic interval. The enum controls instrumentation breadth; it is not a numeric sampling rate, and all can add disproportionate overhead on a CPU-limited host.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	`all`	different	`all`
OLAP	`all`	different	`all`
CRIT	`all`	different	`all`
TINY	`all`	different	`all`

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–19 Beta 3 = all (dcs); OLAP: PG9.0–19 Beta 3 = all (dcs); CRIT: PG9.0–19 Beta 3 = all (dcs); TINY: PG9.0–19 Beta 3 = all (dcs). Advice, pending human review — Editorial inference, pending maintainer review: The explicit all setting maximizes function-level observability across every profile, accepting instrumentation overhead and the SQL-inlining blind spot.

Common pitfalls

Expecting inlined SQL-language functions to appear in function statistics.
Enabling all cluster-wide without measuring instrumentation overhead on function-heavy workloads.
Reading cumulative total and self time without accounting for nested calls and snapshot behavior.
Treating none, pl, and all as levels of sampling rather than different instrumentation scopes.

track_counts · stats_fetch_consistency · compute_query_id · jit_expressions · log_statement_stats