Content deleted Content added
m convert special characters (via WP:JWB) |
Citation bot (talk | contribs) Alter: template type. Add: date, newspaper, pages. | Use this bot. Report bugs. | Suggested by Abductive | #UCB_toolbar |
||
Line 27:
|title=Chapter 62. BRIN Indexes
|url=http://www.postgresql.org/docs/9.5/static/brin-intro.html
}}</ref> Other vendors have described some similar features,<ref name="Herrera, 2013"/> including [[Oracle database|Oracle]],<ref name="Oracle, Exadata Storage Indexes"/><ref name=Solarwinds/> [[Netezza]] 'zone maps',<ref>{{cite web|url=http://nztips.com/2010/11/netezza-integer-join-keys/ |publisher=Netezza|title=With Netezza Always Use Integer Join Keys For Good Compression, Zone Maps, And Joins|year=2010}}</ref> [[Infobright]] 'data packs',<ref>{{cite web|title=Data packs|publisher=[[Infobright]]|url=http://www.infobright.org/Blog/Entry/organizing_data_and_more_about_rough_data_contest/|archive-url=https://web.archive.org/web/20090627103453/http://www.infobright.org/Blog/Entry/organizing_data_and_more_about_rough_data_contest|url-status=dead|archive-date=2009-06-27}}</ref> [[MonetDB]]<ref>{{cite document|title=Cooperative Scans: Dynamic Bandwidth Sharing in a DBMS|year=2007|pages=723–734 |publisher=MonetDB|citeseerx=10.1.1.108.2662}}</ref> and [[Apache Hive]] with ORC/Parquet.<ref>{{cite web|title=Hive Optimizations with Indexes, Bloom-Filters and Statistics|year=2015|publisher=Jörn Franke|url=https://snippetessay.wordpress.com/2015/07/25/hive-optimizations-with-indexes-bloom-filters-and-statistics/
}}</ref>
Line 67:
|url=http://axleproject.eu/2014/11/30/progress-on-online-upgrade/}}</ref>
With BRIN, the slowdown from maintaining the index is much reduced compared to B-tree.<ref>{{cite
|title=Index Overhead on a Growing Table
|date=10 October 2014
|author=Mark Wong
|newspaper=2Ndquadrant | Postgresql
|url=http://blog.2ndquadrant.com/index-overhead-growing-table/
}}</ref> Wong reports that B-tree slowed down additions to an unindexed 10GB table by 85%, but a comparable BRIN only had an overhead of 11%.<ref name="Wong, 2014" />
Line 104 ⟶ 105:
}}</ref> Exadata has the strong concept of a 'storage layer' in its architecture stack. Table data is held in blocks or 'storage cells' on the storage servers. These storage cells are [[block-level storage|opaque to the storage server]] and are returned to the database engine on request, by their identifier. Previously, the database nodes must request all the storage cells in order to scan them.<ref name=Solarwinds>{{cite web
|title=Understanding Storage Indexes in Oracle Exadata
|date=2 June 2015
|url=http://logicalread.solarwinds.com/storage-indexes-oracle-exadata-mc05/#.Vpjbp27fXU8
}}</ref>
| |||