Production performance has four separate dimensions: PostgreSQL's chosen plan, database latency, retrieval quality, and sustainable throughput under concurrency. Use EXPLAIN (ANALYZE, BUFFERS) on safe representative queries, compare ANN with exact results, distinguish warm from cold cache, and trace end-to-end stages. A fast query with weak recall is not an optimization.
ANALYZE executes the query; never use it casually on destructive statements. Inspect scan type, index name, estimated versus actual rows, loops, sort, filter removals, shared hit/read buffers, temporary I/O, planning time, and execution time. Large estimate errors can signal stale statistics or correlated predicates.
Use a production-shaped snapshot, representative query/filter distribution, realistic concurrency and connection pooling, fixed versions, and isolated load-generation hardware. Warm-cache runs answer a different question from restart/cold-read runs. Report both if both matter. Include ingestion or maintenance load if production runs them concurrently.
For each ANN configuration, measure exact recall@k, task metrics, latency distribution, CPU, I/O, buffers, returned rows, and throughput. Plot the Pareto frontier. Reject configurations that violate quality or policy even if they are faster.
Run a low-concurrency baseline, then step load until latency or errors exceed the objective. Repeat enough times to expose variance. Cross-check database execution time with application traces, pool wait, embedding latency, reranking, and generation.
Interpret this PostgreSQL plan and benchmark report [paste]. Separate evidence from hypotheses. Identify estimate errors, filters, index/operator match, buffer behavior, pool wait, tail latency, exact recall, and missing workload realism. Propose one-variable experiments.
Verification contract: Every optimization must show before/after plan, quality, tail latency, resource use, and rollback criteria under the same workload.