同一樣的構思，在一個類資料庫索引構造中儲存一定範疇的資料區塊中某一列的最少和最高值，當查看句子中包括該列的過慮標準時，便會全自動忽視這些毫無疑問不包含滿足條件的列值的資料區塊，進而降低IO載入量，提高查看速率。Exadata的StorageIndex不多說了，由於那並不是資料庫查詢範圍的解決方法，而Oracle資料庫查詢12.1.0.2中的新作用ZoneMaps曾要我十分興奮，可是最後發覺該作用也只有在運作於Exadata上的Oracle中才可以開啟，略心寒。
下列使用Pgwiki中的事例表述BRINindexes的強勁
–建立檢測表orders
–在表格中插進很多紀錄，Pg的涵數generate_series十分功能強大。
–該表現階段有13GB尺寸，算作大表了。
–以全資料表掃描儀的方法查看二天內的紀錄，留意這兒預估必須30s，這是一個儲存在SSD上Pg資料庫查詢，因而速率早已很理想化了。
–下面在order_date列上建立一個BRINindex
–查詢這一BRINindex占是多少物理學室內空間，13GB的表，而BRINindex僅有504KB尺寸，十分精減。
–再度實行同樣的SQL，看一下特性提高是多少。速率升高到只必須6秒左右，提高了5倍。假如它是儲存在HDD上的Pg庫，這一實際效果還能更顯著。
–可以讓客戶自主設置一個range中能夠包括的資料資訊片數，也是很貼心的設計方案。默認設置狀況下一個range包括128個page，我們可以改動為更小或是更高，包括的page越低則精密度越密，相對的BRINindex也便會越大；相反則精密度粗，BRINindex小。
–建立一個每一個range包括32pages的資料庫索引。
–再建立一個每一個range包括512pages的資料庫索引。
–較為一下每個資料庫索引的尺寸。