Find the cause of a slow PostgreSQL query and make a measured improvement. Focus on a query that affects a page or API your users depend on.
Open or import your existing project and provide the affected request or query. You need a disposable database with representative synthetic data. Repository access and database configuration do not transfer with the prompt.
Your agent will compare execution plans and results, then prepare a scoped patch or migration for review. Measurements on test data identify candidates for improvement; they do not establish production performance.
Find and fix one slow PostgreSQL query in my existing app without changing its intended results or access controls. If the repository is unavailable, ask me to open or import it first. Read its instructions and inspect the database driver or ORM, PostgreSQL version, migrations, and test setup. Reuse these tools. Ask for the affected query or request and the expected result if the scope is unclear. If this app uses a different database, explain the mismatch before applying PostgreSQL-specific advice. Use a disposable local or approved test database with synthetic data that represents relevant row counts, skew, and relationships. Confirm the target before running database commands. Never copy customer data or print connection secrets. If no test database is available, inspect code and prepare a reproducible fixture; mark runtime measurements as blocked. Capture the generated SQL with parameter values redacted. Inspect its plan with EXPLAIN, then use EXPLAIN ANALYZE only against the disposable database after checking for side effects, because it executes the statement. Compare estimated and actual rows, repeated work, scans, and sorting. Separate database execution time from connection and application overhead. Repeat comparable measurements rather than relying on one run. Implement a focused query rewrite or index migration supported by the evidence. Preserve parameterized values, tenant filters, ordering, pagination, null behavior, and transaction semantics. Avoid string interpolation for user input. Evaluate index storage and write overhead, migration locking, and a rollback path. Do not run migrations, analyze statements, or other mutations in production without explicit approval. Extend existing tests at the query or request boundary. Compare representative results before and after, including empty results, duplicate sort values, pagination boundaries, and a different tenant where applicable. Exercise database failure handling and ensure the change does not convert errors into successful empty responses. Run the migration and rollback on disposable data when applicable. Report the cause supported by evidence, patch, before-and-after plan and timing method, checks actually run, required setup, and rollout considerations. Clearly separate measured results from predictions that still need a representative environment.