APRIL 2026

Faster EXPLAIN ANALYZE in Postgres 19 & New Deep Dive Series into pg_stat_statements

Hi there,

Last week, Postgres 19 hit feature freeze — meaning the window for new features is now closed, and the community shifts into stabilization mode ahead of the release later this year. Over the next weeks you'll hear more from us on new exciting feature in the upcoming Postgres release.

For today, I wanted to highlight a feature I worked on myself, together with Andres Freund and David Geier: Lower overhead for taking timing measurements in EXPLAIN ANALYZE. I'm sure you've run EXPLAIN ANALYZE before, and wondered why the query seems slower than it actually is. It depends on the query, but the most common cause of slowness is repeated instrumentation start/stop calls as nodes are entered (and measured) during execution. In the upcoming Postgres 19 release, you will see noticeably less overhead from timing, thanks to using the RDTSC instruction directly on x86-64 CPUs. Learn more in 5mins of Postgres episode 122.

We're also kicking off a new special series on Postgres in Production with Ryan Booz: a deep dive into pg_stat_statements. If you've ever relied on this extension for query performance monitoring (and most of us have), this series digs into what it actually tracks, what it doesn't, and the misconceptions that can leave you flying blind when it matters most. Part 1 covering the fundamentals is out now.

As always, you can find the complete list of pganalyze product updates at the end of this newsletter.

Waiting for Postgres 19

Lower overhead for EXPLAIN ANALYZE in Postgres 19

In this episode we talk about a change in the upcoming Postgres 19 release that will lower timing overhead for EXPLAIN ANALYZE. This is a change that the community has worked on for a couple of years now, but for this release we finally figured out all the little details that make this work. The core of how timing got faster: By allowing out-of-order execution of timing measurements through the RDTSC instruction (x86-64), instead of the standard RDTSCP instruction through clock_gettime. Learn all the details through the transcript, or by watching the video:

New Series

pg_stat_statements: Where Postgres Performance Monitoring Begins

In this special series of "Postgres in Production", Ryan Booz takes a deep dive into pg_stat_statements — the essential Postgres extension for tracking query performance.

In Part 1, Ryan covers what pg_stat_statements is, how to enable it, what it tracks (45+ columns as of Postgres 18), and critically — what it doesn't track and why that matters. You'll learn why all metrics are cumulative, what happens when the 5,000 unique query limit is reached, and why treating it as the single source of truth for query performance history can leave you flying blind.

Community News

Upcoming Events

We've just wrapped up a busy stretch on the European conference circuit. It was great connecting with the Postgres community and customers at Nordic PGDay and pgDay Paris, and Ryan's talk on actionable observability was well received. Next up, Ryan is speaking at Postgres Conference 2026 in San Jose, CA (April 21–23), with multiple talks spanning everything from Postgres to beekeeping. In May, the team heads north to PGConf.dev in Vancouver (May 19–22), to talk all things Postgres development. We love meeting community members at these events, so come find us if you'll be there!

Product Updates

What's New in pganalyze

MCP Server (early access)

• Switch to TSV output format for timeseries data
• Introduce tool call rate limiting, see documentation
• Allow API key authentication in addition to OAuth
• Support for Claude on Web, ChatGPT and Cursor clients

pganalyze-collector 0.70.0

• Track nested query statistics separately based on toplevel field
  • This matters when pg_stat_statements.track is set to "all", and allows pganalyze to consider query activity from inside functions, or other nested cases (e.g. EXPLAIN) separately from top level activity (direct query execution)
• Allow resetting pg_stat_statements when nearly full
  • Due to pg_stat_statements deallocating 5% of the least used queries when full (i.e. number of entries hits the pg_stat_statements.max), certain workloads can experience a high rate of <query text unavailable> in pganalyze, due to very old queries with high call counts taking priority over more recent query activity.
  • In such situations, a recurring pg_stat_statements_reset() call can avoid the situation by clearing 100% of entries, so that there is more space for fresh entries
  • This reworks the existing reset mechanism to reset pg_stat_statements when (1) it has utilized most of its entries, and a dealloc is likely occurring soon (2) the returned query text exceeds 250MB
  • Resets are optional and turned off by default. When the helper function exists, and the reset interval is configured through pganalyze, it is now taken as the highest permitted reset frequency, i.e. with this change resets will likely occur less often than before (previously it was a fixed interval that would always reset)
• Keep per-query information on whether a query / query sample was normalized
  • This lets the pganalyze application be informed whether PII filtering was applied to a particular snapshot being submitted.
• Allow multiplexed use of OpenTelemetry logs server
  • Multiple servers can now share the same db_log_otel_server configuration
  • This is safe to do in certain circumstances, specifically when a Kubernetes pod or label filter is in place, and the log message has sufficient details (i.e. is annotated with Kubernetes metadata)
  • If configured without a pod/label filter the collector will emit a warning, and send received logs to each server sharing the same db_log_otel_server
• Kubernetes label matching: Ensure selected labels are present for equality
  • Previously a label specified in the selector, but not actually present in the data would lead to that part of the selector being skipped, not counting it as a mismatch. Instead count it as a mismatch for equality, but a match for inequality.
• Diff pg_stat_statements_info dealloc counter correctly on initial collector start
• Rework OpenTelemetry logs handler to be OTLP spec compliant
• Crunchy Bridge: Don't crash when metrics retrieval fails
• AlloyDB/Cloud SQL:
  • Allow IAM authentication to use private service connect endpoint
    • This is enabled by setting the new gcp_use_psc / GCP_USE_PSC to true
  • Avoid accidental use of prepared statements when IAM authentication is in use
• AlloyDB: Add back support for follower statistics
  • This revises the change added in 0.69.0 to more specifically skip the problematic function on a replica

Query Performance

• Persist table sort order in query string

  • This allows users to navigate back to a page of sorted results (e.g., in the Query Performance list) and maintain the sort order.
• Change statement type filter to exclude DML when only SELECT is checked

  • Previously, any queries that included a SELECT component (like "INSERT ... SELECT" or even "INSERT ... VALUES") were returned. Limiting to SELECT-only is more in line with what users expect from a filter like this.

Automated EXPLAIN

• Improve plan parsing when auto_explain.log_format=text

  • This adds support for JIT output changes in newer Postgres versions and fixes worker detail parsing when auto_explain.log_timing is disabled.

Connections

• Improve how Connection Traces listing responds to date range selection

  • Previously, the selected focus timestamp had inconsistent behavior when the date range is updated, or the focus timestamp itself is updated by clicking on the Wait Events or Connection States graphs.
  • This standardizes its behavior: when a labeled date range is selected (e.g., Last 24h), the selected focus timestamp for the Connection Traces listing is cleared. When an unlabeled date range is selected, if the focus timestamp falls within the new range, it remains unchanged. If it does not, it is reset to the end of the range.

Other Improvements

• Database Dashboard: Show check-up status of all available checks
  • The check-up widget on the database dashboard now covers all check types. Previously, only some checks were shown. Each check group now also displays the number of active issues.
• Checks & Alerts: Do not alert about AlloyDB replicas with fsync=off

  • Also downgrade the alert to a warning if running on a non-AlloyDB replica: this is still worth addressing (since an untimely crash could lead to having to rebuild the replica), but it's unlikely to be a critical issue.

Earn a $25 Now 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.