Statistics / Monitoring

compute_query_id

• What it does: Enables in-core computation of a unique identifier for each query, used for tracking and aggregating statistics across multiple executions of the same query.
• Why it matters: Query identifiers are essential for advanced monitoring and performance analysis, allowing you to track the performance of individual query patterns across multiple executions. This enables powerful analytics like identifying your most frequent or slowest queries, even when they have different parameters. The in-core computation provides more reliable and consistent query identification compared to external methods.
• Ideal value & Best Practice: Default auto is recommended for most environments. Set to on to force query ID computation even when extensions like pg_stat_statements are not loaded. Use off only if you absolutely need to minimize overhead and have alternative query tracking methods.

log_executor_stats

• What it does: Writes detailed executor performance statistics to the server log for each query, showing how the query execution phase performed.
• Why it matters: Provides deep insight into query execution behavior, including row processing, node execution, and other executor-level metrics. This is extremely valuable for advanced performance tuning and understanding how queries actually execute, but generates very verbose output that can significantly impact log volume and performance.
• Ideal value & Best Practice: Default off. Enable only for specific debugging sessions of problematic queries. Never use in production due to extreme log verbosity and performance impact. Combine with other debugging options for comprehensive analysis.

log_parser_stats

• What it does: Writes parser performance statistics to the server log, showing how query parsing and rewriting phases performed.
• Why it matters: Helps identify parsing-related performance issues, which can be important for applications that generate complex SQL or use extensive query rewriting. This is primarily useful for PostgreSQL developers or when troubleshooting specific parsing performance problems.
• Ideal value & Best Practice: Default off. Enable only when specifically debugging query parsing performance issues. The output is highly technical and primarily useful for PostgreSQL core developers rather than typical database administrators.

log_planner_stats

• What it does: Writes detailed query planner statistics to the server log, showing the planning phase performance and decision-making process.
• Why it matters: Provides deep insight into how the query planner processes and optimizes queries, including join planning, index selection, and cost estimation. This is invaluable for understanding why the planner chooses specific execution plans and identifying potential optimization opportunities.
• Ideal value & Best Practice: Default off. Enable temporarily when analyzing planner behavior for complex queries. The output is extremely verbose and should only be used for targeted debugging sessions, not continuous logging.

log_statement_stats

• What it does: Writes cumulative performance statistics for each statement to the server log, providing an overview of total resource usage.
• Why it matters: Offers a summary-level view of statement performance that's less verbose than the individual component statistics (parser, planner, executor). This can be useful for getting a high-level overview of query performance characteristics without the extreme detail of the component-specific options.
• Ideal value & Best Practice: Default off. Consider enabling temporarily for performance analysis when you need more detail than standard logging but less than the component-specific statistics. Still generates significant log output, so use judiciously.

---

Try pghealth Free Today 🚀

Start your journey toward a healthier PostgreSQL with pghealth.
You can explore all features immediately with a free trial — no installation required.

👉 Start Free Trial