---
title: Building Postgres tuning loops with Claude and pganalyze, plus three new Query Advisor insights
---

| On July 30, Lukas shows end-to-end tuning workflows with Claude and the pganalyze MCP Server. Query Advisor now detects inefficient index use & more.  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­    ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏  ͏ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­   |
| --- |

| View in browser JULY 2026 Building Postgres tuning loops with Claude and pganalyze, plus three new Query Advisor insights Hi there,   Since the pganalyze MCP Server moved to public preview, we've seen it become widely used - from data platform teams using it to streamline their processes, to engineers driving investigations across tool boundaries. But we've also gotten questions on how to use the MCP Server effectively. In our upcoming July 30 webinar we'll share what we've learned over the last 4 months, and also preview a new feature: The ability to optionally let AI tools use pganalyze Workbooks to run EXPLAIN ANALYZE, with guard rails. This helps validate query rewrites or settings changes, and enables an effective tuning loop with tools like Claude Code. Register here for the webinar.   Prefer deterministic logic that runs in the background and notifies you? We're excited to introduce three new Query Advisor recommendations. Query Advisor continuously analyzes your EXPLAIN plan data, and now detects index scans that remove too many rows with a filter (instead of an index condition), sorts and hash joins spilling to disk when work_mem is too low, and OR conditions across two joined tables that stop Postgres from using an index. Each insight comes with a recommendation that you can test in a Workbook yourself, or you can have AI tools do the benchmarking for you.   Ryan is back with Part 5 of his pg_stat_statements deep dive, this time on pg_stat_statements configuration, including how pg_stat_statements.max drives deallocations. Every time pg_stat_statements runs out of room, it drops 5% of its entries. That means 250 rows at the default max of 5,000. The pg_stat_statements_info view has a counter for this, and Ryan walks through how to read it over a 10-minute window, plus the settings and application changes that reduce the loss.   On the community side, Postgres 19 Beta 2 is now available. It is not meant for production, but testing and providing bug reports is essential, and helps us all get the best release possible later this year. And if you didn't catch last month's webinar on plan statistics and plan management (including the new PG19 pg_plan_advice module), the recording is now available.   As always, you can find the complete list of pganalyze product updates at the end of this newsletter.   All the best, Lukas Upcoming Webinar pganalyze MCP in Action: Optimizing Postgres with Claude Code and other AI Tools The pganalyze MCP Server made it safe for AI assistants like Claude to read your Postgres monitoring data. Connecting Workbooks to the MCP Server, now in early access, lets them test fixes too: creating a workbook for a slow query, running real EXPLAIN ANALYZE executions through the collector, and comparing a rewrite against the baseline plan. Join Lukas live on Thursday, July 30 to see end-to-end tuning workflows, from first triage to a validated fix. Register for the webinar Product Update New Query Advisor Insights: Inefficient index use, work_mem tuning, and OR to UNION rewrites pganalyze Query Advisor now detects three more common Postgres problems straight from your EXPLAIN plan data: an index that scans far more rows than it returns, sorts and hash joins spilling to disk because work_mem is too low, and OR conditions across two tables that stop Postgres using an index (rewritable as a UNION). Each comes with a specific recommendation you can validate in Workbooks before shipping. Read the announcement New Episode Configuring pg_stat_statements to Reduce Deallocations (Part 5) pg_stat_statements has only a handful of settings, but they decide how much query data you keep and how much you lose. In Part 5 of the Postgres in Production deep dive, Ryan Booz shows how to spot the loss with the deallocation counter in pg_stat_statements_info, what each of the five settings actually does (including why max requires a restart and reserves memory even when tracking is off), and why changing settings is often not enough, but application changes are required: IN lists (before Postgres 18), string concatenation, and querying with large numbers of unique roles. Read the deep dive Watch On Demand Postgres Plan Monitoring & Management: Best Practices & Postgres 19 Missed it live? A plan flip is the most common reason a Postgres query goes from fast to slow without any code change, but Postgres doesn't normally show you which plan ran and when. In the June webinar recording, Lukas walks through how pg_stat_plans makes plan history visible on any modern Postgres deployment, when CREATE STATISTICS or a setting change fixes a bad plan and when you need to hint instead, and what pg_plan_advice in Postgres 19 adds for plan stability. Watch the recording Product Updates What's New in pganalyze Query Advisor New Inefficient Index Use insight This insight detects Index Scan nodes that read many rows only to discard most of them at the filter, and reports when a different existing index exists that could be a better match. New Late Join Filter with OR insight. Detects joins with an OR condition spanning both joined tables, which prevents Postgres from using an index on either side, and flags when existing indexes could support rewriting the query as a UNION. (See this month's feature above for all three new insights that were recently launched.) Index Advisor Support uppercase column names for captured extended statistics. Unused index check: raise the maximum look-back period from 35 to 400 days, so indexes used only occasionally (for example once a year) are not incorrectly flagged. The default is kept at 35 days. Other improvements & bug fixes Workbooks: Suggest queries to start from on the New Workbook page Previously the New Workbook page showed only an empty SQL editor, leaving users without a query in mind to figure out the next step on their own. The page now lists the database's top 10 SELECT queries by % of total runtime over the last 24 hours; clicking any row starts a workbook pre-filled with that query. Persist series selection from the legend across navigation, for example when narrowing the selected time range on the Connections page. Resets to defaults with a full-page reload. Fix search box losing focus while typing Searching the query list no longer drops focus after each keystroke, and a search with no matches now shows an empty table instead of an unrelated setup hint. System: Graph WAL size on WAL & Replication tab Server Groups: Support custom display names Fixed Slack integration setup, and table sorting on the Connections page   Add ability to hide columns in some tables pganalyze Collector v0.71.0 Track temporary file usage per database (temp_files and temp_bytes from pg_stat_database), and track IO worker backends on Postgres 18+ Fix unbounded memory growth when stitching multi-line log events, such as large auto_explain JSON plans: stitched content is now capped at 10MB with a warning, preventing collector OOMs Fix a collector hang on config reload (SIGHUP), and prevent file and goroutine leaks during self-hosted log tailing Faster schema collection on databases with many partitions, and correct ignore_schema_regexp filtering for large partitioned catalogs Earn a $50 Gift Card for a Review on G2 Help us get more community feedback and qualify for a free gift card while supplies last. Review us on G2 Duboce Labs, Inc., 1501 Mariposa St, Unit 408, San Francisco, CA 94107 Unsubscribe Manage preferences |
| --- |