<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Artem Gavrilov — Percona Community</title><link>https://percona.community/tags/pg_artem/</link><description>PostgreSQL articles and insights by Artem Gavrilov on the Percona Community blog</description><generator>Hugo 0.168.0</generator><language>en</language><lastBuildDate>Mon, 19 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://percona.community/tags/pg_artem/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 isPermaLink="true">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>