-
Notifications
You must be signed in to change notification settings - Fork 813
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explicit per-table PG stats #760
Conversation
…-table-stats Conflicts: checks.d/postgres.py
packaging/root/ | ||
/.vagrant/machines/default/virtualbox/id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be /.vagrant/
alone, we don't want anything from that subdir in git.
Conflicts: checks.d/postgres.py
|
||
# Do we need relation-specific metrics? | ||
if relations is None or relations == []: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick but you can just do:
if not relations:
here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I miss string[]
in the function signature...
@alq666 What's the overall status ? |
No need for a __main__ section.
Conflicts: checks.d/postgres.py
@remh should be good to go for a merge. I will add more stats in a later version. |
@alq666 Can you merge back the master branch into your branch and fix the conflicts ? |
… pg-per-table-stats # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
@remh this is for 4.1. I see this is new beginnings more than a definitive PG check.
I have spent some time reworking the check to make the collection of per-table stats easier. There are now up to 3 statistics queries executed: one for all databases, one for all listed tables (or relations in pg parlance) and one for all indices of the listed tables.
Tagging is per database, per table.
There is a number of other metrics we can get. It should be relatively easy to add without altering the structure of the check (in particular the collect_stats part that parses results).
The table list is made explicit to not generate boat loads of useless metrics.
@clofresh probably of interest to you too.