Call for feedback! We need your opinion!

[artemgavrilov]

Description

At Percona, we believe that great open source software is built with the Community, not just for it. As we plan the next iteration of pg_stat_monitor, our advanced PostgreSQL monitoring extension, we’re taking a closer look at the current feature set and how it aligns with real-world usage.

In open source, the community isn’t just a user base, it’s the most important stakeholder. While we set the vision, your feedback is the compass that guides us. Your experiences, bug reports, and feature requests are what validate our direction and keep us focused on what matters most. Without your active involvement, it’s impossible to build a tool that truly solves the problems you face every day. Your input ensures pg_stat_monitor evolves in a way that is both innovative and genuinely useful.

Your Feedback Is the Compass

Over time, pg_stat_monitor has grown beyond its initial query performance monitoring scope.

While many features have proven to be extremely useful (especially in use with Percona Monitoring and Management (PMM)), others may see limited adoption or give no evidence of any adoption at all. To ensure we’re investing in what really matters, we want to understand what you, the users and contributors, actually rely on day-to-day.

We’re especially interested in:

• What features of pg_stat_monitor are critical for your workflows?
• Are you using it together with PMM, CLI or in another way?
• Are there parts of the extension that feel unnecessary or unclear?
• What would you love to see in the next release?

This is just the beginning of a broader review and improvement effort, one that we want to run transparently and inclusively, true to our open source values.

Whether you’re a developer, DBA, or platform engineer using pg_stat_monitor directly or via tools like PMM, know that your input matters.

Please leave a comment below ❤️

Original blog post: https://percona.community/blog/2025/08/13/pg_stat_monitor-needs-you-join-the-feedback-phase/

[smeubank]

While many features have proven to be extremely useful . . . others may see limited adoption or give no evidence of any adoption at all.

@artemgavrilov would it be possible to get more information about the features which are useful and the ones which see very little adoption? I'd also be curious if it is not useful because maybe the data is hard to understand, or figuring out an actual item item is not apparent.

[ImTheKai]

@smeubank That's the actual issue here. There is no data on how to really prove what is useful and what isn't. We are currently gathering feedback from actual users and customers. If you have any items or thoughts, please share them, as we need as much information as possible for a clearer picture. That's the typical issue of open source but also the beauty of it. You only know how good/important something was, once you removed it and people start complaining. I would like to avoid the "complaining" and rather work on a future, that makes sense for the current users.

[danolivo]

I'd like to ask about the mechanisms for representing and gathering statistics.
It seems too simple to store statistics as float8 values: most of the parameters would benefit from kinda a running stats type that includes min/max/mean/count values.

I made the first attempt implementing the RStats type and using it inside the pg_track_optimizer extension. It looks pretty good, reduces the number of fields, and allows extending nblocks statistics without additional columns. What's more, we would minimise storage size, allowing less expensive RStats(int4) type, where min/max/mean/stddev would consume only 4 bytes each.
Also, encapsulating calculations within the custom base type simplifies the extension's code.

You're a pretty popular extension in practice. So, I'd be interested in introducing a complex type to store data for your extension, if that is a good idea in general.

[jiaoshuntian]

I would like to know why, in the tap test, some cases require pg_stat_statements, but there is no
EXTRA_INSTALL = contrib/pg_stat_statements in the Makefile

[artemgavrilov]

@jiaoshuntian It seems that it makes sense to add it. Thanks for pointing out!