Postgres Health Check and SQL Performance Analysis
gitlab.com
gitlab.com
samokhvalov helped us to get this set up
Find next occurence 30 times and look when it's filled in.
If all is good, i think you need a minute or so.
Would love to hear about this use case out of curiosity
In how many databases? Spread across how many machines? Using hardware that is how old?
It may well be a good project, but statements like that aren't inspiring of confidence.
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.
Just in case if it looks surprisingly that Postgres can deal with such numbers of objects, I suggest checking this out: https://www.pgcon.org/2013/schedule/attachments/283_Billion_...
It is a great project, constantly improving. Keep up with the work!
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.