Report Sections¶
When you run quellog without section flags, you get a report with all available sections. Each section can be requested individually with its flag — see Filtering for details. Some flags (e.g., --connections, --tempfiles, --locks) display additional detail not shown in the default report.
Summary¶
SUMMARY
Start date : 2025-01-13 00:00:00 UTC
End date : 2025-01-13 23:59:59 UTC
Duration : 23h59m59s
Total entries : 1,234
Throughput : 8,227 entries/s
SQL Summary (--sql-summary)¶
Shows query execution statistics and load distribution from the default report. For per-query analysis, see SQL Analysis.
SQL SUMMARY
Query load distribution | ■ = 10 s
00:00 - 03:59 ■■■■■■■■■■ 105 s
04:00 - 07:59 ■■■■■■■ 78 s
08:00 - 11:59 ■■■■■■■■■■■■■■ 145 s
12:00 - 15:59 ■■■■■■■■ 89 s
16:00 - 19:59 ■■■■■■ 67 s
20:00 - 23:59 ■■■■ 42 s
Total query duration : 8m 46s
Total queries parsed : 456
Total unique query : 127
Top 1% slow queries : 5
Query max duration : 2.34 s
Query min duration : 12 ms
Query median duration : 145 ms
Query 99% max duration : 1.87 s
Requires log_min_duration_statement >= 0.
Events (--events)¶
Per-severity counts, grouped by SQLSTATE class with one line per
distinct event pattern. Each pattern is preceded by a stable short
identifier (<sev>-<4-char-hash>) usable with --event-detail.
EVENTS
FATAL : 82 (2.1%)
28 - Invalid Authorization Specification
fa-U26K password authentication failed for user ? 3 3.66%
3D - Invalid Catalog Name
fa-Hcoq database ? does not exist 3 3.66%
53 - Insufficient Resources
fa-6K1G sorry, too many clients already 40 48.78%
fa-1bhf remaining connection slots are reserved for roles with th... 36 43.90%
ERROR : 19 (0.5%)
22 - Data Exception
er-VHRD division by zero 3 15.79%
Severity prefixes: pa- (PANIC), fa- (FATAL), er- (ERROR), wa-
(WARNING). Open the per-pattern report with --event-detail.
LOG / INFO / DEBUG / NOTICE counts are reported but not broken down by pattern (no SQLSTATE, no actionable signal).
Error Classes (--errors)¶
PostgreSQL error distribution by SQLSTATE class code.
ERROR CLASSES
42 – Syntax Error or Access Rule Violation : 125
23 – Integrity Constraint Violation : 18
22 – Data Exception : 5
53 – Insufficient Resources : 2
Common classes: 42 (syntax/permissions), 23 (constraint violations), 22 (invalid input), 53 (resources), 08 (connections), 40 (deadlocks).
Info
Requires SQLSTATE codes in logs: %e in log_line_prefix, or csvlog/jsonlog format.
Temporary Files (--tempfiles)¶
Queries that exceeded work_mem and spilled to disk.
TEMP FILES
Temp file distribution | ■ = 10 MB
00:15 - 01:11 ■■■■■■■■■■■■■■■■■■■■■■■■ 249 MB
01:11 - 02:08 ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 389 MB
02:08 - 03:05 ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 300 MB
03:05 - 04:01 ■■■■■■■■■■■■■■■■■■■■■ 214 MB
04:01 - 04:58 ■■■■■■■■■■■■■■■■■ 170 MB
04:58 - 05:55 ■■■■■■■■■■■■■■■■■■■ 194 MB
Temp file messages : 11639
Cumulative temp file size : 48.34 GB
Average temp file size : 4.25 MB
Queries generating temp files:
SQLID Query Count Total Size
------------------------------------------------------------------------------------------------------------
xx-Asa3KN -- probe heap_bloat select current_database() as dbname, sum(bloat_s... 10188 16.66 GB
xx-TtcBPJ with namespace_rels as ( select nsp.oid, nsp.nspname, array_remove(a... 28 7.37 GB
se-SunZ0F select sit_gestion.refresh_referentiel_topo(); 1276 6.52 GB
xx-T3SufA close c17 4 2.56 GB
se-z3k2JB select ?, array_agg(distinct st_srid("geom")::text || ? || upper(geo... 6 2.49 GB
Requires log_temp_files >= 0.
Locks (--locks)¶
Lock contention, wait times, and queries involved.
LOCKS
Total lock events : 194
Waiting events : 171
Acquired events : 23
Avg wait time : 54.92 s
Total wait time : 2h 57m 34s
Lock types:
AccessShareLock 194 100.0%
Resource types:
relation 194 100.0%
Waiting queries:
SQLID Query Acquired Waiting Total Wait
---------------------------------------------------------------------------------------------------------
up-kR4mNx update orders set status = ? where id = ? 12 3 45m 26s
se-Wd9pLa select * from inventory where product_id = ? for upd... 0 8 12m 04s
Blocking queries:
SQLID Query Blocked Avg Wait Total Wait
---------------------------------------------------------------------------------------------------------
up-Tj7bQe update inventory set quantity = quantity - ? where pr... 8 15m 08s 45m 26s
Waiting queries: queries that waited for locks, with acquired/still-waiting counts. Blocking queries: queries that held locks causing others to wait (requires DETAIL: Process holding the lock in logs).
Requires log_lock_waits = on.
Maintenance (--maintenance)¶
Autovacuum and autoanalyze activity, split into two sibling sections so vacuum-specific signals (buffer/WAL, dead-not-removable rows, space reclaimed) stay separate from analyze.
AUTOVACUUM
Vacuum count : 668
Cumulated time : 3h59m17s
Tuples removed : 212,590
Space recovered : 64.00 KB
Dead, not yet removable : 1,506,114
Buffer usage : hits 12M misses 12M dirtied 261k written 0
Slowest single run : 29m33s on appdb.public.app_activity_feed
Top tables by elapsed time:
appdb.public.app_activity_feed 8× 3h52m24s
appdb.public.app_lock 422× 5m23s
appdb.public.app_audit_entry 216× 44s 8.00 KB recovered
Tables with rows not yet removable:
appdb.public.app_activity_feed 784,509 rows
appdb.public.app_lock 696,246 rows
appdb.public.app_audit_entry 22,932 rows
Top tables by count:
appdb.public.app_lock 422 63.2%
appdb.public.app_audit_entry 216 32.3%
AUTOANALYZE
Analyze count : 353
Cumulated time : 1h2m3s
Top tables by elapsed time:
appdb.public.app_lock 300× 52m8s
appdb.public.app_activity_feed 13× 8m58s
Top tables by count:
appdb.public.app_lock 300 85.0%
The header block answers the cluster-wide questions a DBA usually asks first: how much vacuum work happened, how much time it cost, how much disk was reclaimed, whether the xmin horizon is letting dead tuples accumulate, and how the buffer/WAL pressure looked. Each entry is suppressed when its source metric is zero — older PostgreSQL versions or runs without log_autovacuum_min_duration keep a terse output. When PostgreSQL ran an anti-wraparound freeze, a - of which aggressive: N line appears right under Vacuum count.
Each panel below the header answers one specific question:
- Top tables by elapsed time (autovacuum) — which tables cost the most vacuum time, with the "X recovered" suffix in muted italic on rows that actually reclaimed space.
- Tables with rows not yet removable — where dead tuples are accumulating because PostgreSQL hasn't been able to remove them yet (same vocabulary the autovacuum log uses, so a DBA seeing the report recognises the term immediately).
- Top tables by count (autovacuum) — hot tables driving the autovacuum workload by sheer frequency.
- Top tables by elapsed time / Top tables by count (autoanalyze) — symmetric panels for the autoanalyze side; analyze blocks only carry system-usage (elapsed), so there is no buffer / WAL / tuples breakdown here.
Requires log_autovacuum_min_duration >= 0. With it off you only get the header counts (vacuum / analyze) and the per-table count rankings — the elapsed / buffer / WAL / dead-row metrics need the continuation lines PostgreSQL writes after each operation.
Checkpoints (--checkpoints)¶
Checkpoint frequency and performance.
CHECKPOINTS
Checkpoints | ■ = 4
00:00 - 04:00 ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 159
04:00 - 08:00 ■■■■■■■■■■■■■■■■■ 69
08:00 - 12:00 ■■■■■■■■■■■■ 48
12:00 - 16:00 ■ 6
16:00 - 20:00 -
20:00 - 00:00 -
Checkpoint count : 282
Avg checkpoint write time : 29s
Max checkpoint write time : 2m31s
Checkpoint types:
wal 171 60.6% (18.03/h)
time 110 39.0% (11.60/h)
immediate force wait 1 0.4% (0.11/h)
Types: time (by checkpoint_timeout), wal (by max_wal_size), shutdown, immediate (manual).
Additional metrics when available:
- WAL distance / estimate: WAL generated between checkpoints vs PostgreSQL's prediction for the next cycle
- WAL rate / flush rate: I/O throughput during checkpoint writes
- Too Frequent warnings: alerts when checkpoints occur faster than
checkpoint_warningthreshold
Requires log_checkpoints = on.
Server lifecycle (--server)¶
Server-level events reconstructed as a timeline — starts, restarts, shutdown types, backend crashes (with the signal), crash recovery — plus hot configuration changes (parameter "X" changed). Replication health is folded in as a sub-zone.
SERVER
Starts : 2 (first: 2026-01-01 16:00:54)
Timeline:
16:00:54 start database system is ready to accept connections
16:20:04 start database system is ready to accept connections
Replication:
Stream reconnects : 1
Replication terminations : 1 (primary closed walsender, last 16:20:02)
Lines are suppressed when their metric is zero. Other entries appear when present: shutdowns (fast/immediate/smart), reloads (SIGHUP) and the parameters they changed, backend crashes (SIGSEGV ×N), crash recovery, and replication signals such as WAL receive failures and conflicts with recovery.
Connections (--connections)¶
Connection patterns and session durations. The default report shows summary metrics. With --connections, additional session analytics are displayed: duration distribution histogram, and session duration tables by user, database, and host.
CONNECTIONS & SESSIONS
Connection distribution | ■ = 1
00:00 - 00:58 ■■■■■■■■■■■■■■■ 15
00:58 - 01:56 ■■■■■ 5
01:56 - 02:55 ■■■■ 4
02:55 - 03:53 ■■■■ 4
03:53 - 04:51 ■■■■ 4
04:51 - 05:50 ■■■■ 4
Connection count : 36
Avg connections per hour : 1.50
Disconnection count : 23
Avg session time : 1h14m7s
Avg concurrent sessions : 13.45
Peak concurrent sessions : 36 (at 05:50:00)
Requires log_connections = on. Session durations require log_disconnections = on.
Clients (--clients)¶
Unique database entities with activity counts. The default report shows the top 10 per category. With --clients, all entities are displayed.
CLIENTS
Unique DBs : 3
Unique Users : 7
Unique Apps : 9
Unique Hosts : 37
TOP USERS
app_user 1250 42.5%
readonly 856 29.1%
batch_user 423 14.4%
admin 198 6.7%
analytics 145 4.9%
backup_user 52 1.8%
postgres 16 0.5%
TOP APPS
app_server 1342 45.6%
psql 687 23.4%
metabase 456 15.5%
pgadmin 234 8.0%
batch_job 145 4.9%
pg_dump 52 1.8%
pg_restore 12 0.4%
[3 more...]
Cross-tabulations (USER x DATABASE, USER x HOST) help identify access patterns and security anomalies.
Requires user/database/app info in log_line_prefix or csvlog/jsonlog format.