Database Research & Development

  • Home
  • NoSQL
    • NoSQL
    • Cassandra
  • Databases
    • Database Theory
    • Database Designing
    • SQL Server Coding Standards
    • SQL Server
    • PostgreSQL
    • MySQL
    • Greenplum
    • Linux
  • Interviews
    • SQL Server Interviews
    • MySQL Interviews
    • SQL Puzzles
  • DBA Scripts
    • SQL Server DBA Scripts
    • PostgreSQL DBA Scripts
    • MySQL DBA Scripts
    • Greenplum DBA Scripts
  • Home
  • Blog Archives !
  • (: Laugh@dbrnd :)
  • Contact Me !
sqlserverinterviews
Home 2016 August PostgreSQL 9.5: Introduced BRIN – Block Range Index with Performance Report

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

This article is half-done without your Comment! *** Please share your thoughts via Comment ***

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:

1
2
3
4
5
6
CREATE TABLE tbl_ItemTransactions
(
TranID SERIAL
,TransactionDate TIMESTAMPTZ
,TransactionName TEXT
);

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

1
2
3
4
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:

1
2
3
4
5
6
7
SELECT pg_size_pretty(pg_total_relation_size('tbl_ItemTransactions')) AS TableSize;
 
/*
TableSize
------------------
6741 MB
*/

Now Check the performance without any Index:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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:

1
2
3
CREATE INDEX idx_tbl_ItemTransactions_TransactionDate
ON tbl_ItemTransactions
USING BRIN (TransactionDate);

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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.

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

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

Aug 31, 2016Anvesh Patel
Database Theory: What is BRIN (Block Range Index), How is faster than BTREE IndexPostgreSQL: What are the Differences between SQL and PL/pgSQL language in Function
Anvesh Patel
Anvesh Patel

Database Engineer

August 31, 2016 PostgreSQLAnvesh Patel, block range index, brin, database, database research and development, dbrnd, horizontal partitioning, plpgsql, Postgres Query, postgresql, postgresql 9.5, PostgreSQL Administrator, PostgreSQL Error, PostgreSQL Programming, PostgreSQL Tips and Tricks, query performance
About Me!

I'm Anvesh Patel, a Database Engineer certified by Oracle and IBM. I'm working as a Database Architect, Database Optimizer, Database Administrator, Database Developer. Providing the best articles and solutions for different problems in the best manner through my blogs is my passion. I have more than six years of experience with various RDBMS products like MSSQL Server, PostgreSQL, MySQL, Greenplum and currently learning and doing research on BIGData and NoSQL technology. -- Hyderabad, India.

About DBRND !

dbrnd

This is a personal blog (www.dbrnd.com).

Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated.

Feel free to challenge me, disagree with me, or tell me I’m completely nuts in the comments section of each blog entry, but I reserve the right to delete any comment for any reason whatsoever (abusive, profane, rude, or anonymous comments) - so keep it polite.

The content of this website is protected by copyright. No portion of this website may be copied or replicated in any form without the written consent of the website owner.

Recent Comments !
  • Anvesh Patel { Sure will do... } – May 27, 12:43 PM
  • Anvesh Patel { Great... } – May 27, 12:41 PM
  • Anvesh Patel { Great... } – May 27, 12:39 PM
  • Anvesh Patel { Great... } – May 27, 12:36 PM
  • Anvesh Patel { Great... } – May 27, 12:28 PM
  • Anvesh Patel { Great... } – May 27, 12:27 PM
  • Anvesh Patel { Great... } – May 27, 12:16 PM
  • Older »
Follow Me !
  • facebook
  • linkedin
  • twitter
  • youtube
  • google
  • flickr
© 2015 – 2019 All rights reserved. Database Research & Development (dbrnd.com)
Posting....