The newly introduced BRIN (Block Range Index) Index is one my favourite index type of RDBMS system like PostgreSQL.

The BRIN index is stored the only summary of data pages instead of storing actual key data. It is 10 times faster than the normal BTREE Index.

I have already published articles on What is BRIN and How we can implement BRIN in PostgreSQL 9.5.?

Database Theory: What is BRIN (Block Range Index), How is faster than BTREE Index

PostgreSQL 9.5: Introduced BRIN – Block Range Index with Performance Report

In this post, I am sharing maintenance part of BRIN Index.

Database Administrators are doing maintenance of Indexes on a regular basis like Rebuild Index, Reorganize Index, Update Statistics of Indexes.

But these types of maintenance will not work for BRIN Indexes because BRIN Indexes are not storing any actual data and it stores only a summary of the data page.

PostgreSQL 9.5 also introduced brin_summarize_new_values() BRIN Index maintenance function.
This function is used to find a new range of pages which are not yet summarized by BRIN Index.

It performs the table scanning and creates a new summary index tuple for newly added data pages and adds into BRIN Index. It also returns a count of total newly added pages.

The syntax is:

SELECT brin_summarize_new_values('BRIN_Index_Name');

Please read this previous article, To Understand the Power of BRIN – Block Range Index.

Database Theory: What is BRIN (Block Range Index), How is faster than BTREE Index

PostgreSQL 9.5 introduced the powerful BRIN Index, which is performance much faster than the regular BTREE Index.
The most important two lines of the BRIN are: It stores only minimum and maximum value per block so it does not require more space. For extremely large table It runs faster than any other Indexes.

In this post, I am going to show the example of BRIN index with the full performance report (testing over the 6gb of Table Data).

Below are steps:

First create one sample table:

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

Insert Millions of data to test the performance of BRIN Index:

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

Check the total size of table:

SELECT pg_size_pretty(pg_total_relation_size('tbl_ItemTransactions')) AS TableSize;

/*
    TableSize
------------------
    6741 MB
*/

Now Check the performance without any Index:

EXPLAIN ANALYSE 
SELECT COUNT(1) FROM tbl_ItemTransactions 
WHERE TransactionDate BETWEEN '2012-01-01 00:00:00' and '2014-08-08 08:08:08';
/*
--Result:
			QueryPlan
-------------------------------------------------------------------------
Aggregate  (cost=2997896.81..2997896.82 rows=1 width=0) 
	(actual time=40651.793..40651.793 rows=1 loops=1)
  ->  Seq Scan on tbl_itemtransactions  (cost=0.00..2894105.00 rows=41516724 width=0) 
	(actual time=0.009..38726.686 rows=41054645 loops=1)
        Filter: ((transactiondate >= '2012-01-01 00:00:00+05:30'::timestamp with time zone) 
		AND (transactiondate <= '2014-08-08 08:08:08+05:30'::timestamp with time zone))
        Rows Removed by Filter: 94377356
Planning time: 0.860 ms
Execution time: 80651.837 ms
*/

Create BRIN index on TransactionDate Column:

CREATE INDEX idx_tbl_ItemTransactions_TransactionDate
ON tbl_ItemTransactions
USING BRIN (TransactionDate);

Now Check the performance of the same query which has BRIN index:

EXPLAIN ANALYSE 
SELECT COUNT(1) FROM tbl_ItemTransactions 
WHERE TransactionDate BETWEEN '2012-01-01 00:00:00' and '2014-08-08 08:08:08';
/*
			QueryPlan
---------------------------------------------------------------------------
Aggregate  (cost=2014834.09..2014834.10 rows=1 width=0) 
	(actual time=7108.998..7108.998 rows=1 loops=1)
  ->  Bitmap Heap Scan on tbl_itemtransactions  (cost=425666.42..1911042.28 rows=41516724 width=0) 
	(actual time=16.995..5415.086 rows=41054645 loops=1)
        Recheck Cond: ((transactiondate >= '2012-01-01 00:00:00+05:30'::timestamp with time zone) 
		AND (transactiondate <= '2014-08-08 08:08:08+05:30'::timestamp with time zone))
        Rows Removed by Index Recheck: 21579
        Heap Blocks: lossy=261632
        ->  Bitmap Index Scan on idx_tbl_itemtransactions_transactiondate  
		(cost=0.00..415287.24 rows=41516724 width=0) (actual time=15.547..15.547 rows=2616320 loops=1)
              Index Cond: ((transactiondate >= '2012-01-01 00:00:00+05:30'::timestamp with time zone) 
              AND (transactiondate <= '2014-08-08 08:08:08+05:30'::timestamp with time zone))
Planning time: 0.059 ms
Execution time: 7109.060 ms
*/

Now, you can see the difference between the result of the above two queries.
With the BRIN index same query took only 7 seconds and without BRIN it took around 80 seconds.

Create Partial BRIN index on TransactionDate Column:
You can also create Partial BRIN index for your individual range of data. The Partial BRIN index is also faster than normal BRIN index, but we should apply proper filter based on created Partial BRIN index.

CREATE INDEX idx_tbl_ItemTransactions_TransactionDate_2012
ON tbl_ItemTransactions
USING BRIN (TransactionDate)
WHERE TransactionDate BETWEEN '2012-01-01' AND '2012-12-31';

CREATE INDEX idx_tbl_ItemTransactions_TransactionDate_2013
ON tbl_ItemTransactions
USING BRIN (TransactionDate)
WHERE TransactionDate BETWEEN '2013-01-01' AND '2013-12-31';

The BRIN index is very new type of index in a Database System.

Currently we are using B-Tree indexes most, but BRIN Indexes are much faster than B-Tree Indexes.
It is not correct to say that BRIN is a 100% replacement of B-Tree but in some situation, it executes 10 times faster than B-Tree Index.

Let me provide you a small note on B-Tree as well,

The structure of B-Tree looks like a Binary Search Tree.
If you have a large table, overall branching of BTree Index is very large because it required to store thousands of keys in a B-Tree node.

The B-Tree also stored all the key values in their leaf nodes so for every search key lookups require to scan both the leaf node and B-Tree mapping node.

If we have very large table with the B-Tree index and we are selecting a large number of records, B-Tree index lookup will slow down the query performance.
The B-Tree index also takes more database space and maintenance is also very costly for a large database table.

What is BRIN (Block Range Index):

The BRIN is a new database indexing technique, mainly design for very large table.

We know about the Table Partitioing concept, which we require to implement on a very large table.
The BRIN index also works like Horizontal Table Partitioning, by creating a different block of data.
If we are using BRIN, we do not require to implement Table Partitioing explicitly.

The BRIN index creates different block of data and it defines range using MinMax function.
Every block has one Min value and Max value associated which is used to identify a related block of data.
A block range is a group of pages that are physically adjacent in the table, for each block range, some summary info is stored by the index.

The BRIN index is a very lightweight because it stores only summery of the data block. Unlike B-Tree indexes, it doesn’t require to store all key node value in index page.

An Even entire form of BRIN indexes can easily store in the memory because of its compact form and it reduces the scanning of the disk.
As it is stored only summary of block so it is also 10 times faster than B-Tree for INSERT and UPDATE operations.

The creation of the BRIN indexes on a large table are also much faster than B-Tree indexes.
The efficiency of BRIN index is also depends on the physical order of table data.

The BRIN indexes are scanning the tuples bases on a bitmap and it returns only those tuples which are matched in block range summary information so It also avoids scanning of the large parts of the table.

The B-Tree indexes are still superior for random searches, and we should use the BRIN indexes for specific type of queries which are mostly used in BIGDATA, Reporting, Data Warehouse.

Please visit next post, for one practical example of BRIN Index in PostgreSQL 9.5.