Optimizations: Where the Suggestions Come From

Every suggestion in the Optimizer is anchored to a query your database actually ran, priced in dollars, and tagged with how sure the system is about it. This page explains where a suggestion comes from, what it carries, and how to check one — before and after you apply it.

Where a suggestion comes from

The agent runs inside your network and reads pg_stat_statements from a read-only replica. It raises only what is visible in that log, in two shapes:

• Full scan — a fingerprint whose cost is dominated by reading a table it has no usable index for.
• Missing index — a fingerprint that a specific index would resolve, with the DDL to create it.

Nothing is invented. A suggestion that cannot be attached to a fingerprint you actually ran does not get raised, and there is no separate plan cache to go stale — pg_stat_statements is the whole input.

What a suggestion carries

That is the whole object. There is no hidden score, no separate severity and no second opinion to reconcile: a table, a type, a monthly figure, a confidence, and the statement to run.

The confidence score is not decoration

The list is ordered by predicted saving × confidence, and the two numbers are allowed to disagree. A suggestion worth $1.19/month at 60% confidence sorts above one worth $2.15 at 35%, because the second one is mostly a guess. In a workspace with a real query log, confidence scores land in the middle of the range — a long list of 95% certainties would mean the score is being flattered.

Read it the way you would read a weather forecast: the ranking tells you what to look at first, not what will happen.

Applying one — and what Praxion will not do

• Nothing is applied to your database by Praxion. The panel hands you the DDL.
• You take it from there — copy it into a pull request, or apply it through the API. Either way the change is yours, made with your credentials, on your schedule.
• Suggestions themselves are never charged. Only the ones you apply count against your plan, alongside text-to-SQL queries. Observing your query log is included in every plan.

How to verify one

Before applying it: check that the table in the row is the one you already suspected, and that the DDL matches what you would have written. A suggestion that names the wrong table is a signal to look at the query log yourself, which is exactly the behaviour you want from a tool that shows its work.

After applying it: the panel keeps two figures apart on purpose — what is still being wasted on inefficient queries, and what has been recovered once applied, with a count of how many suggestions have actually been applied. If the second number is not moving, nothing has been fixed.

Behind both: the audit log. It is append-only and hash-chained, and make audit-verify checks its integrity. Only state changes are recorded — applying an optimization, editing the glossary, changing a role, connecting a database. Reads are not events, so nobody has to page through "somebody opened the panel" to reach the approval that mattered.