Loops change the math
Node timings are per loop; buffers already represent accumulated work. The tool handles those units separately.
Quantitative, local, explainable analysis
Find where time really goes, compare estimates with execution, measure buffers, and validate an optimization — without executing SQL or uploading the plan.
Text or JSON; automatic detection.
Self time, total time, loops, and buffers.
Findings with evidence and confidence.
Current plan against a baseline.
Node timings are per loop; buffers already represent accumulated work. The tool handles those units separately.
Function Scan shows outer cost, not nested statements. Opaque findings recommend instrumentation instead of a blind index.
Single plans do not show frequency, write cost, or the full workload. Validate before changing production.
From calculation to real operations
Use this plan as a starting point. Then connect PostgreSQL to validate configuration against real load, concurrency, I/O, WAL, autovacuum, and query behavior — continuously, not only on tuning day.
Assisted diagnostic: we never request passwords or connection strings through forms, email, or WhatsApp.
What the SaaS tracks in PostgreSQL
No. Parsing, calculations, and diagnostics all run in your browser. No query is executed, uploaded, or stored by PG Monitoring.
For PostgreSQL, prefer EXPLAIN (ANALYZE, BUFFERS, WAL, SETTINGS, FORMAT JSON). For MySQL, use EXPLAIN ANALYZE FORMAT=TREE; JSON v2, JSON v1, and traditional table output are also accepted.
It is an approximation of inclusive node time minus child time, with loops applied correctly. Parallelism and instrumentation can overlap, which the tool flags.
Yes. Paste the new plan in the main field and the previous one in the optional field. The tool compares execution, work volume, and access-method changes; for PostgreSQL it also compares JIT and buffers.
No. A single plan does not reveal write cost, frequency, or the full workload. The tool presents evidence and a next step while keeping the decision reviewable.