PostgreSQL: From vague "DB is slow" to concrete actions I know how to debug a particular slow query with explain analyze (PostgreSQL).

If I received vague "DB is slow" feelings, I worked with this answer: https://stackoverflow.com/a/12818168/633961

In my case there are no sequence scans. I guess a combined index is missing.

Is there a tool which can help me to find missing combined indexes? 

Other strategies which help to solve the goal are welcome, too.

Update

According to Julien Rouhaud this is fixed in PostgreSQL 10: https://groups.google.com/d/msg/powa-users/UmIEWvgJ2-k/sS5lfRE4CAAJ
To resolve overall DB slow, these are the things you can look into in Postgres:

1- 

 -- Lock monitoring
 SELECT relation::regclass, * FROM pg_locks WHERE NOT GRANTED;


-- To find waiting queries
SELECT pid, datname, usename, now() - query_start AS runtime, wait_event,
wait_event_type, state, query FROM pg_stat_activity WHERE wait_event
is NOT NULL AND state = 'active';


-- To look at what all is running
select * from pg_stat_activity;


-- Once you have identified the session that is blocking you, you can kill it as below, make sure you don't kill someone's else work,
-- check with DBA if unsure (replace blocking_pid with pid that is blocking your session)


   SELECT pg_terminate_backend(pg_stat_activity.pid)
FROM pg_stat_activity
WHERE pg_stat_activity.datname = 'your_db'
  AND pid &lt;&gt; pg_backend_pid() and pid='blocking_pid';


2- Make sure autocommit is enabled in your client (This is especially an issue in DBeaver)

3- If there is no lock, let's generate an explain plan to see what is the cost of the query and places where we can improve. How to generate an explain plan

4- You might have to vacuum the tables if there have been large DML, it is also advisable to collect stats after any large DML, by default vacuum and stats collection happen automatically. (See link above for info n VACUUM, too).

5- Regarding your combined index, that will depend on the slow queries, there is no automated way to check that, you can however make sure that your foreign keys are indexed and that you can check using information_schema views.