400 for max connections is usually what is recommended max

https://pgtune.leopard.in.ua/#/
PostgreSQL cannot use a cache(shared buffer) bigger than 8GB as per rob and what he read in
PostgreSQL High Performance. ?

Effective cache size is just a guideline for the query planner.

Shared buffers should be a quarter of total ram e.g with 32gb Ram its 8GB and I tested with 64GB and it
was 16GB

The number of connections are originally 100 but as you move up the RAM in increases.
work_mem is for sorting/complex sorts. How much memory do you want to
allocate for complex sorting. This work_mem is alloted for any query
that comes in. so roughly work_mem = 55924kB that is 55mb per query.
So if multiplied by max connections it can eat up a lot of memory.

maintenance_work_mem is memory that will be used for most background

processes: pg_dump, pg_restore, vacumming, indexing and index
creation. So give this a good amount of memory or go with what pgtune
tell you.

Writing of data to disk is done in little segments and that’s where

checkpoint_segments come in. for every 3 segments there will be a
write to disk. Increasing this value will mean writs to disk will not
happen as often.
wal_buffers max value is 16MB used for writing transactions to disk.
Letting PostgreSQL Tell Us What's Wrong

http://www.craigkerstiens.com/2013/01/10/more-on-postgres-performance/

Read PostgreSQL 9 High Performance

https://www.youtube.com/watch?v=fva7qn9Yg3o

Indexes ?

Installing pg_stat_statements
The pg_stat_statements module provides a means for tracking execution statistics of all SQL
statements executed by a server.

pg_stat_statements is basically a monitor

https://www.postgresql.org/docs/9.4/static/pgstatstatements.html

https://pganalyze.com/docs/install/01_enabling_pg_stat_statements/
Restart the PostgreSQL server

You can reset statistics with:

https://github.com/jeffchulg/dbatoolbelt/tree/master/postgres

Top Queries

http://www.craigkerstiens.com/2013/01/10/more-on-postgres-performance/

SELECT
(total_time / 1000 / 60) as total_minutes,
(total_time/calls) as average_time,
query
FROM pg_stat_statements
ORDER BY 1 DESC
LIMIT 100;

Cache Usage

http://www.craigkerstiens.com/2012/10/01/understanding-postgres-performance/
SELECT
sum(heap_blks_read) as heap_read,
sum(heap_blks_hit) as heap_hit,
sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) as ratio
FROM
pg_statio_user_tables;
A cache hit ratio of 99% is good. Else if it’s lower increase your cache.

Index Usage

Fixing Slow Queries