Skip to main content

Queries tab

The Queries tab uses pg_stat_statements to surface the most impactful queries by total time, call count, and tail latency.

Requirements​

The pg_stat_statements extension must be installed and loaded. Without it, the Queries tab shows limited information and several tuning recommendations lose their primary signal.

Top queries​

Queries are ranked by total execution time. Each row shows:

  • Query text (normalized by pg_stat_statements)
  • Total time, calls, avg time, rows
  • P95 and P99 estimated latency

Tail latency estimation​

When only summary statistics are available, pocketPG estimates tail latency from pg_stat_statements timing distribution fields. Low-volume queries are filtered so one-off calls do not create noisy alerts.

Tail latency insights​

The tab surfaces queries whose tail latency, variance, or total time indicate operational risk. Severity reflects both user-visible latency and how different the tail is from the average case.

Exact severity gates are intentionally not published. The UI shows the evidence used for each finding so you can decide whether to investigate, tune, or ignore it.

Wait event correlation​

On PostgreSQL 14+, each latency insight is enriched with the active wait event (from pg_stat_activity) when the query is currently running. This replaces generic "common causes" text with specific wait-type hints (Lock, IO, IPC, LWLock, etc.).

Extension recommendations​

Computed after latency insights, returned in the same response. The app looks for extension opportunities such as:

  • trigram search for substring matching workloads
  • JSONB indexing when containment or path access appears frequently
  • partition-management tooling for large time-oriented workloads
  • automatic plan capture for highly variable or slow queries
  • table maintenance tooling when bloat and vacuum lag appear together
  • prepared statement guidance when planning overhead is meaningful

Already-installed extensions are excluded automatically.

Query regression detection​

The browser keeps a lightweight local baseline between page loads. If a query gets noticeably slower compared with the previous baseline, the UI marks it as regressed.

Caching​

Query data is short-lived cached to avoid repeated heavy reads while still keeping the dashboard fresh.