PostgreSQL Performance Analysis & Tuning
PostgreSQL is an open source database which is used widely due to its strong reputation for
reliability, feature robustness, performance and strong community support.
It is common that more data centric applications need regular database health check and
performance analysis and maintaince for the better performance of the application irrespective of
environment and platforms.
Database requires below activities to ensure the performance and maintained well.
1. Configuration changes based on the usage
2. Query Optimization
3. Index Creation & Maintaince
4. Database design
5. Auto Vacuum and Analyzing
6. Long Running Queries
Configuration changes based on the usage
1. max_connections
a. Recommendation is 4 * CPU cores else 100 by default
2. shared_buffers
a. Default size is 128 MB
b. LEAST (RAM/2, 10GB)
3. work_mem
a. Default size is 4 MB
b. ((Total RAM - shared_buffers) / (16 x CPU cores))
4. maintenance_work_mem
a. Default size is 64 MB
b. This memory is used for vacuum, Create index and foreign Key DDL
5. idle_in_transaction_session_timeout
o Min is 0 ms
o Max is 10 ms if application handles
Query Optimization
1. Avoid Having clause and wildcard search wherever possible
2. For large data set avoid User defined functions for the descriptions try to join the table
instead to get the name or description
3. Avoid sub queries
4. Use loops instead of Cursors in the coding
5. Use NOT EXISTS instead of NOT IN
6. In Views or any joins use specific required columns instead of all columns (select * from ..)
Index Creation & Maintaince
1. Creating index will improve performance drastically so need to revisit queries to ensure all
main columns are indexed.
2. Need to check usage of index and remove unused indexes
a. select * from pg_stat_all_indexes where schemaname <>
'pg_catalog';
3. Rebuild index improves performance when large amount data has been modified.
4. REINDEX provides a way to reduce the space consumption of the index by writing a new
version of the index without the dead pages
a. REINDEX INDEX my_index_name;
b. REINDEX TABLE my_table_name;
c. REINDEX DATABASE my_db_name;
Database Design
1. Well-designed data model to achieve normalization
2. Partitioning on the large tables
3. Index creation in the required columns
4. Establishing the constraints properly across the tables
5. Proper column datatypes in the tables
6. Avoid triggers wherever it is not required
Auto Vacuum and Analyzing
1. The auto vacuum feature reallocates the deleted block of data.
2. Prevents Table Bloating
3. Optimized Storage Space
4. Vacuum Types
a. Standard Vacuum
i. It In this type of vacuuming, the command removes dead tuples and marks
space as available for using it. It only free up the disk space for PostgreSQL
b. Full Vacuum
i. This Vacuum type reclaims the disc space to OS by rewriting the entire table
5. Monitoring Vacuum
a. SELECT relname, last_vacuum, last_autovacuum FROM
pg_stat_user_tables;
6. Auto Vacuum for the table
a. ALTER TABLE table SET (autovacuum_vacuum_scale_factor = 0.05);
Long Running Queries
1. When database performance is slow then need to check on the long running queries and
even the history to fine tune the query
SELECT *
FROM pg_stat_activity WHERE datname IS NOT NULL
AND state = 'active'
ORDER BY query_start;
2. Setting for the query timeout
SET statement_timeout TO 1000
3. Killing Long-Running PostgreSQL Queries
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE (now() - pg_stat_activity.query_start) > interval '2
minutes';
4. Show PostgreSQL Locks
SELECT pid, relation::regclass, mode, granted
FROM pg_locks
JOIN pg_stat_activity ON pg_locks.pid = pg_stat_activity.pid;
