That's a huge wall of text to digest every time the report is run. It would be nice if there was a diff mode that could summarize what changed between two runs.
One single database. Yes, quite unusual case of multi-tenant database. We needed to use checkup there a while ago so made some optimizations.
I agree with you, the statement is not 100% clear. We will double-check it (and maybe will simulate the case in CI), and will improve the statement. Thank you.
We have been using postgres-checkup for quite a while. Indeed, we have standardized on it as the basis on which we elaborate the health check and performance report analysis that we provide to our support customers.
It is a great project, constantly improving. Keep up with the work!
This seems like a great idea. I used to have a collection of magic Postgres queries that would give me metrics for optimizing data models and indices. I’m surprised there isn’t a visual tool you can bolt into your Postgres install and get valuable metrics out.
The footprint is very minimalistic. I have 15+ years of Postgres DBA experience, and what this tool does basically is what I usually do myself with performing Postgres health checks under heavy load. But in automated fashion :)
We very carefully choose approaches and queries that we run on production servers. And it is used under heavy loads (dozens of thousands of TPS) daily.
There are certain places that can be heavy. For example, if you have 1 million indexes (yes, it happens, sometimes), the SELECT query for bloat analysis will be slow. Actually, with default settings, the tool limits itself setting `statement_timeout = '30s'` (can be adjusted using CLI option `--statement-timeout`). So, in databases with a huge number of objects, you should expect that F004 and F005 reports will be missing.
samokhvalov helped us to get this set up