"debugging performance" is otherwise known as profiling. Googling "PostgreSQL profiling" will yield more and more accurate results than "debugging PostgreSQL pe

"debugging performance" is otherwise known as profiling. Googling "PostgreSQL profiling" will yield more and more accurate results than "debugging PostgreSQL performance". A good wiki article on the topic is: https://wiki.postgresql.org/wiki/Performance_Analysis_Tools https://wiki.postgresql.org/wiki/Performance_Analysis_Tools Then, slow queries are not necessarily slow all the time. Sometimes they are slow depending on how populated a table is, or it is slow for specific records that have lots of relationships (e.g: a record for a user that is more active than the rest). In this case, getting: averages, min, max, std deviation, etc... gives you an idea of what is going on. Then, once you've narrowed down the queries that are acting up, there are many things you can do: 1) Optimize the query: use the execution plan (with the EXPLAIN command) to find if there is any abnormal thing such as queries over fields that are not indexed, or if the query scope is too broad, etc. 2) Basic schema optimization: add an index, denormalize, etc. 3) Reduce call count (caching results) or provide more specific parameters to reduce the scope of the query. 4) Advanced optimization: partitioning, sharding, etc. Overall, I did not like the problem solving approach of the article.