This is inspired by the first responder kit from Brent Ozar for SQL Server, which is an amazing tool for accidental DBAs that do not know where to start optimizing.
I'm looking forward to trying this out on my postgres databases.
Why are indexes on foreign keys required? If I'm doing a join, it's going to select the primary key of the other table, how will an index on the foreign key help?
Does the unused index feature look into replicas? (I guess it doesn't) It's risky to delete an unused index by looking at a single instance, since it may be used by other read replicas.
Hey everyone! Justin here (randoneering). Thanks for posting a link to the github repo!
I will try to sum up answers to your questions by suggesting you look at my roadmap in the repo on where it will be heading. I only included a few health checks at the start because I wanted to keep milestones reachable. And, because I am working full time, three kids, sole provider, and try not to spend all my time in front of a screen. So I will be adding more as we go along the way.
Regarding adding this as a view-yup, that's on the list. Same with having this export directly to a table.
The intention of this function is to avoid being overly complex for general users, but allow for folks who want to dive into the details to be able to do so as well. Brent and his team have some great "filter" options with sp_blitz that give you all the info you could ask for (bring the pain) or the general health check. That is one of my favorite features and want to implement something similar. The view would help make this easier!
I have a pr that will be merged shortly to avoid the issue with folks naming their tables with special characters, capital letters, etc. Should have figured this would come up but was on my list to handle in the next wave of work. But seeing as this escalated very quickly...looks like it will be merged today pending testing against pg15-18.
Just want to say THANK YOU for your comments, suggestions, and feedback. I look forward to moving this along with the community!
10 comments
[ 4.4 ms ] story [ 163 ms ] threadDid you consider making this a view instead? Just curious if there is a reason why you couldn't.
There are multiple reasons for tables not having primary keys. Log tables are one example.
Excessive sequential scans is also not a problem for small tables.
I'm looking forward to trying this out on my postgres databases.
[1] https://bucardo.org/check_postgres/
[2] https://github.com/lob/pg_insights
Clearly you don't have the kind of "load all invoice lines belonging to this invoice" type workloads that I'm used to. Is it all OLAP?
Is this a typo? I would think that 10MB seems ridiculously small for a threshold here.
I will try to sum up answers to your questions by suggesting you look at my roadmap in the repo on where it will be heading. I only included a few health checks at the start because I wanted to keep milestones reachable. And, because I am working full time, three kids, sole provider, and try not to spend all my time in front of a screen. So I will be adding more as we go along the way.
Regarding adding this as a view-yup, that's on the list. Same with having this export directly to a table.
The intention of this function is to avoid being overly complex for general users, but allow for folks who want to dive into the details to be able to do so as well. Brent and his team have some great "filter" options with sp_blitz that give you all the info you could ask for (bring the pain) or the general health check. That is one of my favorite features and want to implement something similar. The view would help make this easier!
I have a pr that will be merged shortly to avoid the issue with folks naming their tables with special characters, capital letters, etc. Should have figured this would come up but was on my list to handle in the next wave of work. But seeing as this escalated very quickly...looks like it will be merged today pending testing against pg15-18.
Just want to say THANK YOU for your comments, suggestions, and feedback. I look forward to moving this along with the community!