The Case for Continuous Query Analysis

Database workloads are not static. The same application, unchanged, produces a different query mix on Monday morning than on Saturday night, at month-end close than mid-month, after a marketing campaign than before it. Data volume grows, distributions skew, and plans that were optimal at one scale become liabilities at another.

A dashboard captures a moment. An optimization decision made from a single snapshot is a decision made about a workload that no longer exists.

A query that ran on a nested loop over a thousand rows behaves entirely differently once the table holds ten million. The SQL text is identical; the cost is not. The planner's choice depends on statistics, on data distribution, and on parameter values that change from execution to execution.

This is why point-in-time EXPLAIN output is a weak basis for tuning. It describes one plan for one set of inputs. The optimization surface is the distribution of plans across real executions over time.

Observed continuously, a workload exposes patterns that snapshots hide: queries whose plans flip between runs, statements whose latency has been degrading gradually, access patterns that no longer match the indexes built for them, and periodic spikes that correlate with maintenance windows or batch jobs.

These signals are only visible as trends. A regression that adds fifty milliseconds per week is invisible in any single measurement and obvious across eight weeks of them.

The objection to continuous analysis is cost: won't watching the database constantly slow it down? Only if done naively. Continuous does not mean heavy. It means sampling the right catalogs and cumulative statistics that the database already maintains, reading them cheaply, and reserving expensive inspection for the rare cases that justify it.

Argyronix treats continuous query analysis as a read-only discipline by default, building a picture of the workload from data the engine is already keeping, so the act of watching stays effectively free.