As long as we're overhauling standard monitoring queries for PostgreSQL, here's another one. This query helps you find indexes which are relatively unused, and as a result could probably be dropped. I wrote a more complex (yes, really) version for our internal Performance Health Check suite, but the linked version is usable by anyone.
The query is also an example of why CTEs, otherwise known as "WITH statements", are a life-saver for working with complex queries. I've only tested it on 9.2 and 9.3; I don't know if it'll work on older versions.
Before you use it, you need to check how long you've been collecting data into pg_stat_user_indexes and friends. The default is since you created the database, but some people reset stats on a daily or monthly basis. So it's important to know what you're looking at. Don't make the mistake of dropping the indexes which are needed for the month-end reports!
The query divides seldom-used indexes into four groups:
Indexes Which Aren't Scanned At All: these indexes have no scans during the stats period. These pretty much certainly can be dropped, except those on really small tables which you expect to grow later.
Seldom Used Indexes on Heavily Written Tables: as a general rule, if you're not using an index twice as often as it's written to, you should probably drop it. This query is a little more conservative than that.
Really Large, Seldom-Used Indexes: these indexes get used, but not that often, and they're taking up a lot of RAM and storage space. Consider dropping them after some thought about why they were added.
Large Non-BTree Indexes On Busy Tables: as a rule, non-BTree indexes like GiST and GIN don't accurately report usage stats. As a result, we can't check how often they're used, just how big they are and if they're attached to tables which get a lot of writes. This list of indexes should be very judiciously pruned.
Happy pruning!
The query is also an example of why CTEs, otherwise known as "WITH statements", are a life-saver for working with complex queries. I've only tested it on 9.2 and 9.3; I don't know if it'll work on older versions.
Before you use it, you need to check how long you've been collecting data into pg_stat_user_indexes and friends. The default is since you created the database, but some people reset stats on a daily or monthly basis. So it's important to know what you're looking at. Don't make the mistake of dropping the indexes which are needed for the month-end reports!
The query divides seldom-used indexes into four groups:
Indexes Which Aren't Scanned At All: these indexes have no scans during the stats period. These pretty much certainly can be dropped, except those on really small tables which you expect to grow later.
Seldom Used Indexes on Heavily Written Tables: as a general rule, if you're not using an index twice as often as it's written to, you should probably drop it. This query is a little more conservative than that.
Really Large, Seldom-Used Indexes: these indexes get used, but not that often, and they're taking up a lot of RAM and storage space. Consider dropping them after some thought about why they were added.
Large Non-BTree Indexes On Busy Tables: as a rule, non-BTree indexes like GiST and GIN don't accurately report usage stats. As a result, we can't check how often they're used, just how big they are and if they're attached to tables which get a lot of writes. This list of indexes should be very judiciously pruned.
Happy pruning!