<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Pg_stat_monitor on Percona Community</title><link>https://percona.community/categories/pg_stat_monitor/</link><description>Recent content in Pg_stat_monitor on Percona Community</description><generator>Hugo</generator><language>en-us</language><copyright>© Percona Community. MySQL, InnoDB, MariaDB and MongoDB are trademarks of their respective owners.</copyright><lastBuildDate>Mon, 19 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://percona.community/categories/pg_stat_monitor/index.xml" rel="self" type="application/rss+xml"/><item><title>Make pg_stat_monitor stable again!</title><link>https://percona.community/blog/2026/10/19/pg-stat-monitor-2-4-0/</link><pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate><guid>https://percona.community/blog/2026/10/19/pg-stat-monitor-2-4-0/</guid><description>&lt;p&gt;pg_stat_monitor started as a fork of pg_stat_statements, built to be a more advanced replacement for it. It provides more detailed information about query execution and groups it in configurable time buckets, so you can look at what happened in a particular time window. It also powers the Query Analytics feature in Percona Monitoring and Management (PMM). However, over time other work took priority at Percona, and the extension stopped getting the attention it needed. The original developers moved on to other things, and the reasoning behind several design decisions went with them. For a couple of years it stayed in maintenance mode, we were fixing reported bugs, and never stepped back to look at deep architectural issues. All that led to a degraded user experience and stability issues.&lt;/p&gt;</description></item></channel></rss>