In this post, I am sharing few important system or statistics views which we can use for monitoring the PostgreSQL Server.

We should monitor the different statistics of the server which help us for improving the overall database performance.

Below are few important views:

Return the running queries/connections information:

select * from pg_stat_activity

Return the SSL information for each connection:

select * from pg_stat_ssl

Check the database statistics:

select * from pg_stat_database

Check the table statistics:

select * from pg_stat_all_tables

Check the system table statistics:

select * from pg_stat_sys_tables

Check the index statistics:

select * from pg_stat_all_indexes

Check the user functions statistics:

select * from pg_stat_user_functions

In this post, I am sharing one of the best practice we can use in our day to day work with PostgreSQL.

pg_stat_activity – we are using this view for finding the information of running queries. In the result of this view, we can see one column which is Application_Name. Which shows the application name of database connection.

More than 90% of PostgreSQL people are not using this column or feature.
In our project, thousand of adhoc queries, DBA queries, user queries and application queries are running in PostgreSQL Server.

I defined the Application name for each group and set the rule, like for all DBA and User has to set the application name before executing their query.

So, now I can easily monitor the purpose of the query by checking the Application_name column of pg_stat_activity.

Check the demo:

Set application name in one of my session:

SET application_name = 'test_activity';

Check the result:
In the result, you can find the query of test_activity application.

select *from pg_Stat_activity;

PostgreSQL 9.6 introduced new two columns of table pg_stat_activity. The columns are wait_event_type and wait_event.

The column wait_event_type reports the type of event a backend is waiting for, and the wait_event which is the name of the event being waiting for. These both columns are very useful for finding a query event information.

Please check small demonstration of this:

Create a sample table:

CREATE TABLE tbl_students(rno int, name character varying(10));

Put your table in lock mode:

BEGIN TRANSACTION;
LOCK tbl_students IN ACCESS EXCLUSIVE MODE;

Open a new query session, and try to insert a below record:

INSERT INTO tbl_students VALUES (1,'Anvesh');

Open a new query session, and check the output of pg_stat_activity:

SELECT query, wait_event_type, wait_event FROM pg_stat_activity

In this post, I am sharing one script to find information about the Locks which are held by Open Transactions of PostgreSQL Database Server.

Database Theory: What is Timeout, Lock, Block, and Deadlock in a Database System?

PostgreSQL view pg_locks contains the main information about the all types of lock of Database Server.
It contains one row per active lockable object.

This script is very helpful to all PostgreSQL Database Administrators.

Below is a script:

SELECT 
	pl.pid AS ProcessID
	,psa.datname AS DatabaseName
	,psa.usename AS UserName
	,psa.application_name AS ApplicationName
	,ps.relname AS ObjectName
	,psa.query_start AS QueryStartTime
	,psa.state AS QueryState
	,psa.query AS SQLQuery
	,pl.locktype
	,pl.tuple AS TupleNumber
	,pl.mode AS LockMode
	,pl.granted -- True if lock is held, false if lock is awaited
FROM pg_locks AS pl 
LEFT JOIN pg_stat_activity AS psa
	ON pl.pid = psa.pid
LEFT JOIN pg_class AS ps
	ON pl.relation = ps.oid

In this post, I am sharing one of the important script to kill all running idle connections and sessions of the PostgreSQL Database.

I have prepared this script such a way that you can also filter idle connections base on a particular time interval.

We are Database Administrator, and this is our responsibility to check idle connection periodically and if it requires to kill, we should do it.

To kill the connections is always not advisable, but in large systems where lots of transactions are going on in that situation we should kill idle connections base on a particular time interval.

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'Database_Name'
	AND pid <> pg_backend_pid()
	AND state in ('idle', 'idle in transaction', 'idle in transaction (aborted)', 'disabled') 
	AND state_change < current_timestamp - INTERVAL '15' MINUTE;

In this post, I am sharing a script to find sessions that are blocking other sessions in PostgreSQL.

Instead of finding blocked sessions or processes, sometimes it is better to find those sessions which are the root of blocking.

PostgreSQL DBA can use this script to find the cause of blocked transactions.

SELECT 
	pl.pid as blocked_pid
	,psa.usename as blocked_user
	,pl2.pid as blocking_pid
	,psa2.usename as blocking_user
	,psa.query as blocked_statement
FROM pg_catalog.pg_locks pl
JOIN pg_catalog.pg_stat_activity psa
	ON pl.pid = psa.pid
JOIN pg_catalog.pg_locks pl2
JOIN pg_catalog.pg_stat_activity psa2
	ON pl2.pid = psa2.pid
	ON pl.transactionid = pl2.transactionid 
		AND pl.pid != pl2.pid
WHERE NOT pl.granted;

In this post, I am sharing a psql script to find a running or active sessions and connections of PostgreSQL.

This script is handy for PostgreSQL DBA.
I am using this same script for our productions PostgreSQL server.

Below is a script:
I filtered “idle connections”

SELECT 
	pid
	,datname
	,usename
	,application_name
	,client_hostname
	,client_port
	,backend_start
	,query_start
	,query	
FROM pg_stat_activity
WHERE state <> 'idle'
AND pid<>pg_backend_pid();