Added Percentage of dead tuples in maintenance tab

[maknahar]

Fixes: #227

Added a column in the maintenance tab to show the percentage of dead rows in tables. This can be useful in the following scenario:

• To make sure that no table is bloated to an unacceptable level
• To figure out if any table requires more aggressive vacuum than configured

Screenshot:

[maknahar]

@ankane Did you get a chance to have a look at this? Please let me know if you want any change.

[ankane]

Hey @maknahar, thanks for the PR! Can you go into more details about the two scenarios? Specifically, the problems that can arise, how to detect them, and how you'd instruct users to address them?

[maknahar]

@ankane Thanks for the response. Both of the scenarios are kind of related. Recently in one of the our Postgres Database, we faced an issue where simple queries started taking a lot of time. Autovacuum was showing green as well. However, after doing a little bit of digging, we found out that the table has bloated up heavily. The table in question was updated very frequently.

This issue happens in various scenarios. For example, when the vacuum could not catch up with DB insert/update, Some misconfiguration in a vacuum setting etc.

The objective of showing this percentage is to make it easier for a user to detect this which will not just help in performance but also optimize the storage cost if Postgres is deployed in cloud.

[maknahar]

How to detect them?

Typical symptoms of this would be slowness in properly indexed queries.

and how you'd instruct users to address them?

Once this issue is detected, there are a few different ways to handle it depending on the situation in hand. If space used by dead rows can be left with the table, the user can check and modify auto vacuum settings. If not, Vacuum full works if we can afford to block DB write. If that is not possible, there are few third-party tools as well which can help.

[ankane]

Thanks @maknahar, let me think about this one. I can see it being useful in some situations, but not sure it'll be used by a majority of users, and PgHero tends to bias towards keeping things simple for the majority.

Edit: The above applies to the UI. I don't think there's any downside to adding the data to the Ruby method.

[maknahar]

@ankane I will completely understand if you do not want to merge it.

Let me know if you feel this information can be shown somewhere. For example, on home page when the dead and live rows ratio goes above some threshold.

[fourseven]

As one data point I'm a happy user of PgHero and would support seeing more stats in the UI. As a tangent we occasionally struggle with IO load during peak times and have considered adding the iostats to PgHero as a PR or fork (but haven't gotten around to it).

I love your work, and think more information is more useful for people trying to easily debug database performance issues.

[ankane]

Decided to merge behind a query parameter (?dead_rows=t). This way, users who need it can access it while keeping things simple for most users (and there are other features that already do this).

Thanks @maknahar!

Edit: Also updated the denominator to be live rows + dead rows so it's an actual percentage (and will stay between 0 and 100). My bad, live rows is actually better since that's what autovacuum uses in its calculation (pg_class.reltuples). This won't be a true percentage, but it'll allow for a better comparison with autovacuum_vacuum_scale_factor.

Ref: https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM

[maknahar]

@ankane Should we add the references for this option (and other options like this) in README somewhere?

[ankane]

I don't think it makes sense to add right now (most users don't need to worry about this), but will add it if I decide to add the other features in the same bucket.