When Runtime Plans Enter the Prompt: A Structured Debate for SQL Review Bots

During a mid-afternoon database spike, a checkout query exceeded its performance budget. The reviewer copied the execution plan, which included actual row counts, hit counts, and a filter on a customer email that should remain confidential. The nested loop query appeared cheap in the EXPLAIN output but expensive in the EXPLAIN ANALYZE output. This prompted the reviewer to seek a second opinion from a model. The question arose: should runtime plans be included in the model context?

Static SQL text is straightforward to version control and replay, but it may not accurately reflect selectivity after the last ANALYZE. Runtime plans, however, provide truthful information about the specific host, cache, and parameter set, and they also expose occupancy. Teams that already have cost-effective review jobs face a dilemma, as the cost of calling a model is no longer the primary concern. The real challenge lies in the legality and usefulness of the bytes that are sent.

Most SQL review discussions begin with the model, prompt template, or merge gate. While these components are important, they ultimately inherit whatever the collector decides to send. A bot that only sees canonical SQL cannot comment on suboptimal execution plans chosen by the optimizer for individual tenants. Conversely, a bot that sees a raw EXPLAIN ANALYZE can comment on the specific loop and also memorize sensitive information such as email addresses, row counts implying revenue, or bitmap heap scans that expose table sizes.

The debate surrounding this issue treats the collector decision as the core product. The focus is on qualitative and operational evidence rather than vendor rankings, as vendor benchmarks become outdated quickly. The artifact is a redaction pipeline and a decision rule that allows for a fair evaluation without fully endorsing either side.

The first position argues that runtime plans are the only honest signal. They claim that SQL review without cardinality is mere decoration. A reviewer who never sees actual rows may praise a predicate and overlook a scan. Shipping a sanitized plan is seen as a duty, not an optional debugging feature. Proponents also argue that estimated EXPLAIN is a weak compromise, as it relies on stale statistics and fails to consider buffer cache warmth.

This group believes that a snapshot plan obtained from a restored database snapshot is closer to production reality than a static schema dump. Additionally, they point out that engineers already paste execution plans into chat platforms during incidents, and a review bot that refuses plans does not reduce leakage; it merely shifts it to unmanaged tools.

Therefore, they advocate for a controlled collector that strips identifiers, retains actual rows, shared hit blocks, and node types.

The opposing position views runtime plans as a telemetry leak. They consider EXPLAIN ANALYZE as production telemetry, akin to a slow-query log rather than source code. Actual row counts can reveal table growth, buffer hits indicate whether the working set fits in memory, and filter values, even if they resemble statuses, may contain tenant keys.

Once these bytes enter a model provider log, the retention policy changes from the database level to the model provider's. This group also doubts the debugging value of a single plan. A single ANALYZE run represents a sample, not a distribution, and models tend to overweight the sample they can see. A query that is cheap at one time of day and slow during a batch job will only teach the model the noon plan.

As a result, teams may optimize for the sample plan while inadvertently harming other periods of high load. Static SQL and schema remain crucial for the model, as they highlight invariants such as missing joins, implicit casts, unparameterized IN lists, and unbounded DELETE statements. Moreover, they raise concerns about operational coupling.

Collecting EXPLAIN ANALYZE from a live primary can slow down the system, write to temporary storage, and potentially disrupt the cache. Collecting it from a replica executes the query without affecting the primary. While snapshot restores are safer, they require additional setup, such as a refresh job, disk space, and a definition of "recent enough."

If the review process is intended to be cost-effective, the restore job itself may be more expensive than the model call. Hence, this side prefers to keep the bot focused on canonical SQL, fingerprints, and schema, leaving runtime plans to human review.

Both positions emphasize the need for evidence that does not rely on vendor benchmarks. PostgreSQL's documentation confirms that EXPLAIN ANALYZE actually executes the statement, which is why EXPLAIN ANALYZE on UPDATE is not a read-only operation. The documentation also notes that the BUFFERS metric reports cache hits and reads, providing insights into the actual cache behavior rather than a logical cost.

These facts already create a division between those who want cache-aware numbers and those who refuse to export such information. Query fingerprints from pg_stat_statements offer a third evidence class. The fingerprint remains stable across different bind values, aiding grouping but compromising selectivity. Depending on whether the review corpus consists of fingerprints or full-text data, the positions take opposing stances on the value of retaining raw execution plan data.

Instead of choosing a side, this artifact presents the trade-offs in a format that can be compared side by side. The redaction pipeline removes sensitive information such as output lists containing column values and filters them out, replacing them with placeholders while preserving essential details like node type, join type, actual rows, and shared hit blocks. This approach proposes a policy for handling execution plans but remains unverified until reviewed by the security team.