As I am preparing important scripts for SQL Server DBA, so here I am also sharing one more vital script for finding the unused indexes of SQL Server Database.

The management and maintenance of database index is a day to day exercise for a Database Administrator. The wrong or unused index can create performance issues for a frequently used table.

At every insert and update, the data of an index are also changing, and it requires some IO operations. Better to find the unused index and delete it.
I also added “DropStatement” column in script for dropping unused Indexes.

SELECT 
	OBJECT_NAME(i.OBJECT_ID) AS ObjectName
	,i.name AS UnusedIndexName	
	,8 * SUM(au.used_pages) AS IndexSizeInKB
	,CASE
		WHEN i.type = 0 THEN 'Heap'  
		WHEN i.type= 1 THEN 'Clustered' 
		WHEN i.type=2 THEN 'Non-Clustered'   
		WHEN i.type=3 THEN 'XML'   
		WHEN i.type=4 THEN 'Spatial'  
		WHEN i.type=5 THEN 'Clustered columnstore index'   
		WHEN i.type=6 THEN 'Nonclustered columnstore index'  
		WHEN i.type=7 THEN 'Nonclustered hash index.'
	END index_type
	,'DROP INDEX ' + i.name + ' ON ' + OBJECT_NAME(i.OBJECT_ID) AS DropStatement
FROM sys.indexes AS i 
LEFT JOIN sys.dm_db_index_usage_stats AS dius 
	ON dius.OBJECT_ID = i.OBJECT_ID 
		AND i.index_id = dius.index_id 
		AND dius.database_id = DB_ID() 
INNER JOIN sys.partitions AS p 
	ON p.OBJECT_ID = i.OBJECT_ID 
		AND p.index_id = i.index_id 
INNER JOIN sys.allocation_units AS au 
	ON au.container_id = p.partition_id 
WHERE OBJECTPROPERTY(i.OBJECT_ID, 'IsIndexable') = 1 
	AND OBJECTPROPERTY(i.OBJECT_ID, 'IsIndexed') = 1 
	AND dius.index_id IS NULL
	OR (dius.user_updates > 0 
		AND dius.user_seeks = 0 
		AND dius.user_scans = 0 
		AND dius.user_lookups = 0)
GROUP BY OBJECT_NAME(i.OBJECT_ID), i.name, i.type 
ORDER BY OBJECT_NAME(i.OBJECT_ID)

Other SQL Server Index related DBA Scripts:

SQL Server: Script to find Redundant and Duplicate Indexes

SQL Server: Script to find Index Average Fragmentation in Percentage

SQL Server: Script to find Missing Indexes

SQL Server: Script to find Index Operational Stats

I have received a few emails related to PostgreSQL default cluster index and I have received from the developers of Microsoft SQL Server.
If you are Microsoft SQL Server developer, you know that Primary key of the Table is working as Cluster Index and resides in the same data page where data actually stored.

In PostgreSQL, There is no concept like: Table Primary Key means default Cluster Index of that table.
In PostgreSQL, we have one CLUSTER command which is similar to Cluster Index.

Once you create your table primary key or any other Index, you can execute the CLUSTER command by specifying that Index name to achieve the physical order of the Table Data.

CLUSTER instructs PostgreSQL to cluster the table specified by table_name based on the index specified by index_name. The index must already have been defined on table_name.

A clustering on an index forces the physical ordering of the data and you can have only one clustered index per table and should carefully pick which index you will use to cluster.

When a table is clustered, it is physically reordered based on the index information. Clustering is a one-time operation: when the table is subsequently updated, the changes are not clustered. That is, no attempt is made to store new or updated rows according to their index order.

If you wish, you can periodically recluster by issuing the CLUSTER command again and again.

A executing of CLUSTER command requires an ACCESS EXCLUSIVE lock on the table because It reorders your data. You can also get some free space by issuing CLUSTER because It rearranges the data in a particular order.

When you execute the CLUSTER command, It creates a temporary copy of the table therefore, you need free space on disk at least equal to the original table size.

When an index scan is used, a temporary copy of the table is created that contains the table data in the index order. Temporary copies of each index on the table are created as well. Therefore, you need free space on disk at least equal to the sum of the table size and the index sizes.

It is advisable to set maintenance_work_mem to a reasonably large value before clustering.

Once you are done with your CLUSTER, you should execute the ANALYZE command on that table because planner records statistics about the ordering of tables.

Syntax of Cluster:
First time you must execute CLUSTER using the Index Name.

CLUSTER table_name USING index_name;

Cluster the table:
Once you have executed CLUSTER with Index, next time you should execute only CLUSTER TABLE because It knows that which index already defined as CLUSTER.

CLUSTER table_name;

Cluster all tables of database:

CLUSTER;

If you are searching about, What is Expression Index, this is the one of the right article for you.

We know about the different types of PostgreSQL Index.
If you don’t about this, please visit below few links.

What is BRIN (Block Range Index )?

What is Partial Index?

What is BTree Index?

Most of the Database Administrators or Developers are doing a common mistake,
When you create any Index on Table Column, dose not mean that you can use the Indexed column in any expression and Index will work as per the expectation.

When you used Indexed column in any kind of expression, query planner simply skips the scanning of Indexes of that column.

For example,
We have created one index on Date column and in WHERE are extracting days from this Date column.
In this situation, the Index will not work on Date column and for such specific requirement, we have to create the Expression Index of PostgreSQL.

Let me demonstrate this.

First create one sample table:

CREATE TABLE tbl_ItemTransactions 
(
	TranID SERIAL
	,TransactionDate TIMESTAMPTZ
	,TransactionName TEXT
);

Generate sample data for testing the performance of Indexes:

INSERT INTO tbl_ItemTransactions 
(TransactionDate, TransactionName)
SELECT x, 'dbrnd' 
FROM generate_series('2015-01-01 00:00:00'::timestamptz, '2016-08-01 00:00:00'::timestamptz,'2 seconds'::interval) a(x);

Total inserted record count is 24969601:

SELECT COUNT(1) FROM tbl_ItemTransactions;

Now create index on TransactionDate column:

CREATE INDEX idx_tbl_ItemTransactions_TransactionDate
ON tbl_ItemTransactions (TransactionDate);

Lets see the plan of query with date filter:

EXPLAIN ANALYZE
SELECT *FROM 
tbl_ItemTransactions 
WHERE TransactionDate BETWEEN '20150808' AND '20160108';
/*
"Index Scan using idx_tbl_itemtransactions_transactiondate on tbl_itemtransactions  
(cost=0.44..249472.54 rows=6681405 width=18) 
(actual time=61.558..17765.979 rows=6609601 loops=1)"
"Index Cond: ((transactiondate >= '2015-08-08 00:00:00+05:30'::timestamp with time zone) AND 
(transactiondate <= '2016-01-08 00:00:00+05:30'::timestamp with time zone))"
"Planning time: 87.751 ms"
"Execution time: 29691.279 ms"
*/

Check Index usage by above query
(Result is one index scan):

SELECT *
FROM pg_stat_user_indexes
WHERE indexrelname='idx_tbl_itemtransactions_transactiondate';

Lets see the plan of query with date function filter:

EXPLAIN ANALYZE
SELECT *FROM 
tbl_ItemTransactions 
WHERE EXTRACT(day FROM TransactionDate) = 8;
/*
"Seq Scan on tbl_itemtransactions  
(cost=0.00..533587.00 rows=124848 width=18) 
(actual time=1246.093..37028.883 rows=820800 loops=1)"
"  Filter: (date_part('day'::text, transactiondate) = '8'::double precision)"
"  Rows Removed by Filter: 24148801"
"Planning time: 0.396 ms"
"Execution time: 58230.847 ms"
*/

Check Index usage by above query:
The Result is one index scan, means above query processed without scaning any index.
We created one index on TransactionDate, but when we use this column with any of default function, planner skips the index fot that column.

SELECT *
FROM pg_stat_user_indexes
WHERE indexrelname='idx_tbl_itemtransactions_transactiondate';

Now we should create one expression Index:
Please provide your require timezone otherwise It produces error like:

ERROR: functions in index expression must be marked IMMUTABLE

CREATE INDEX idx_tbl_ItemTransactions_TransactionDate_day
ON tbl_ItemTransactions ((EXTRACT(day FROM TransactionDate AT TIME ZONE 'UTC')));

Lets execute same query with date function filter:

EXPLAIN ANALYZE
SELECT *FROM 
tbl_ItemTransactions 
WHERE EXTRACT(day FROM TransactionDate AT TIME ZONE 'UTC') = 8;
/*
"Bitmap Heap Scan on tbl_itemtransactions  (cost=2340.01..160893.01 rows=124848 width=18) 
(actual time=367.653..2181.489 rows=820800 loops=1)"
"  Recheck Cond: (date_part('day'::text, 
(transactiondate)::timestamp without time zone) = '8'::double precision)"
"  Heap Blocks: exact=5248"
"  ->  Bitmap Index Scan on idx_tbl_itemtransactions_transactiondate_day  
(cost=0.00..2308.80 rows=124848 width=0) 
(actual time=365.386..365.386 rows=820800 loops=1)"
"        Index Cond: (date_part('day'::text, 
(transactiondate)::timestamp without time zone) = '8'::double precision)"
"Planning time: 0.297 ms"
"Execution time: 3608.713 ms"
*/

Check created new Expression Index usage by above query
(Result is one index scan):

SELECT *
FROM pg_stat_user_indexes
WHERE indexrelname='idx_tbl_itemtransactions_transactiondate_day';