Monitoring your Postgres database is important. But its actually not as easy as it sounds. Postgres itself does not expose enough information, or sometimes data is exposed that can be misinterpreted. In this session we'll spend time looking at specific cases that are blank spots on the map right now, where one either doesn't know what Postgres is up to, or where you have to use system-level tools and other creative methods to get information. Some examples of what we'll take a look at: The deceptive value of buffer hit counters, the multiple efforts to bring planning data to pg_stat_statements, and why you often have to resort to "perf" to identify performance bottlenecks. You'll leave this session with more ideas on how to work around these short-comings, as well as an understanding of where development effort is going to fix some of the issues.