Histogram-Aware Sorting for Enhanced Word-Aligned Compress

Similar documents
Sorting Improves Bitmap Indexes

All About Bitmap Indexes... And Sorting Them

Analysis of Basic Data Reordering Techniques

Enhancing Bitmap Indices

arxiv: v4 [cs.db] 6 Jun 2014 Abstract

C-Store: A column-oriented DBMS

Efficient Common Items Extraction from Multiple Sorted Lists

Lawrence Berkeley National Laboratory Lawrence Berkeley National Laboratory

Architecture of C-Store (Vertica) On a Single Node (or Site)

Track Join. Distributed Joins with Minimal Network Traffic. Orestis Polychroniou! Rajkumar Sen! Kenneth A. Ross

Data Compression for Bitmap Indexes. Y. Chen

Bitmap Index Partition Techniques for Continuous and High Cardinality Discrete Attributes

COMP 430 Intro. to Database Systems. Indexing

Query Processing on Multi-Core Architectures

Query Processing and Optimization Using Set Predicates

Bitmap Indices for Fast End-User Physics Analysis in ROOT

Hybrid Query Optimization for Hard-to-Compress Bit-vectors

A Comparison of Memory Usage and CPU Utilization in Column-Based Database Architecture vs. Row-Based Database Architecture

Fast Retrieval with Column Store using RLE Compression Algorithm

Minimizing I/O Costs of Multi-Dimensional Queries with Bitmap Indices

C-STORE: A COLUMN- ORIENTED DBMS

Parallel, In Situ Indexing for Data-intensive Computing. Introduction

Column-Stores vs. Row-Stores: How Different Are They Really?

Better bitmap performance with Roaring bitmaps

Information Retrieval

Processing of Very Large Data

Efficient Iceberg Query Evaluation on Multiple Attributes using Set Representation

Strategies for Processing ad hoc Queries on Large Data Warehouses

Daniel Lemire, Waterloo University, May 10th 2018.

Advanced Data Management Technologies

US Patent 6,658,423. William Pugh

Data Warehouse Physical Design: Part I

Impact of Column-oriented Databases on Data Mining Algorithms

Storage hierarchy. Textbook: chapters 11, 12, and 13

Compressing and Decoding Term Statistics Time Series

Overview of Data Exploration Techniques. Stratos Idreos, Olga Papaemmanouil, Surajit Chaudhuri

COLUMN STORE DATABASE SYSTEMS. Prof. Dr. Uta Störl Big Data Technologies: Column Stores - SoSe

In-Memory Data Structures and Databases Jens Krueger

Indexing and Hashing

Concise: Compressed n Composable Integer Set

Andrew Pavlo, Erik Paulson, Alexander Rasin, Daniel Abadi, David DeWitt, Samuel Madden, and Michael Stonebraker SIGMOD'09. Presented by: Daniel Isaacs

Citation for published version (APA): Ydraios, E. (2010). Database cracking: towards auto-tunning database kernels

HICAMP Bitmap. A Space-Efficient Updatable Bitmap Index for In-Memory Databases! Bo Wang, Heiner Litz, David R. Cheriton Stanford University DAMON 14

Compressing Social Networks

DW Performance Optimization (II)

Web Information Retrieval. Lecture 4 Dictionaries, Index Compression

Something to think about. Problems. Purpose. Vocabulary. Query Evaluation Techniques for large DB. Part 1. Fact:

Data Warehouse Physical Design: Part I

Column Stores vs. Row Stores How Different Are They Really?

Outline. Database Management and Tuning. Index Data Structures. Outline. Index Tuning. Johann Gamper. Unit 5

Why Operating Systems? Topic 3. Operating Systems. Why Operating Systems? Why Operating Systems?

Exadata X3 in action: Measuring Smart Scan efficiency with AWR. Franck Pachot Senior Consultant

SAP IQ - Business Intelligence and vertical data processing with 8 GB RAM or less

Keynote: About Bitmap Indexes

In-Memory Data Management Jens Krueger

Evolution of Database Systems

Crescando: Predictable Performance for Unpredictable Workloads

Bitmap Indices for Speeding Up High-Dimensional Data Analysis

DATABASE PERFORMANCE AND INDEXES. CS121: Relational Databases Fall 2017 Lecture 11

CS 525: Advanced Database Organization

Evolving To The Big Data Warehouse

COLUMN-STORES VS. ROW-STORES: HOW DIFFERENT ARE THEY REALLY? DANIEL J. ABADI (YALE) SAMUEL R. MADDEN (MIT) NABIL HACHEM (AVANTGARDE)

Index Compression. David Kauchak cs160 Fall 2009 adapted from:

CSE 562 Database Systems

Accelerating Analytical Workloads

Spatially-Aware Information Retrieval on the Internet

A Rough-Columnar RDBMS Engine A Case Study of Correlated Subqueries

Indexing. Week 14, Spring Edited by M. Naci Akkøk, , Contains slides from 8-9. April 2002 by Hector Garcia-Molina, Vera Goebel

A CSP Search Algorithm with Reduced Branching Factor

Algorithms. Lecture Notes 5

Database Optimization

Massive Parallel Join in NUMA Architecture

Approximate Encoding for Direct Access and Query Processing over Compressed Bitmaps

7. Query Processing and Optimization

Optimizing Query Execution for Variable-Aligned Length Compression of Bitmap Indices

Heap-Filter Merge Join: A new algorithm for joining medium-size relations

I. Introduction. FlashQueryFile: Flash-Optimized Layout and Algorithms for Interactive Ad Hoc SQL on Big Data Rini T Kaushik 1

Staying FIT: Efficient Load Shedding Techniques for Distributed Stream Processing

STREAM VBYTE: Faster Byte-Oriented Integer Compression

AtCoder World Tour Finals 2019

Lecture 12. Lecture 12: Access Methods

Column Store Internals

Basic Compression Library

Caches Concepts Review

Binary Search and Worst-Case Analysis

Join Execution Using Fragmented Columnar Indices on GPU and MIC

An O(n 2.75 ) algorithm for online topological ordering 1

Web page recommendation using a stochastic process model

UpBit: Scalable In-Memory Updatable Bitmap Indexing. Guanting Chen, Yuan Zhang 2/21/2019

Announcement. Reading Material. Overview of Query Evaluation. Overview of Query Evaluation. Overview of Query Evaluation 9/26/17

Unit 3 Fill Series, Functions, Sorting

PFAC Library: GPU-Based String Matching Algorithm

Unit 3 Functions Review, Fill Series, Sorting, Merge & Center

Database Group Research Overview. Immanuel Trummer

A Case for Merge Joins in Mediator Systems

A Framework for Clustering Massive Text and Categorical Data Streams

Data-Parallel Algorithms on GPUs. Mark Harris NVIDIA Developer Technology

Query Processing and Optimization using Set Predicates.C.Saranya et al.,

Module 9: Selectivity Estimation

TrajStore: an Adaptive Storage System for Very Large Trajectory Data Sets

Transcription:

Histogram-Aware Sorting for Enhanced Word-Aligned Compression in Bitmap Indexes 1- University of New Brunswick, Saint John 2- Université du Québec at Montréal (UQAM) October 23, 2008

Bitmap indexes SELECT * FROM T WHERE x=a AND y=b; Above, compute {r r is the row id of a row where x = a} {r r is the row id of a row where y = b}

Bitmap indexes SELECT * FROM T WHERE x=a AND y=b; Bitmap indexes have a long history. (1972 at IBM.) Above, compute {r r is the row id of a row where x = a} {r r is the row id of a row where y = b}

Bitmap indexes SELECT * FROM T WHERE x=a AND y=b; Bitmap indexes have a long history. (1972 at IBM.) Long history with DW & OLAP. (Sybase IQ since mid 1990s). Above, compute {r r is the row id of a row where x = a} {r r is the row id of a row where y = b}

Bitmaps and fast AND/OR operations Computing the union of two sets of integers between 1 and 64 (eg row ids, trivial table)... E.g., {1, 5, 8} {1, 3, 5}?

Bitmaps and fast AND/OR operations Computing the union of two sets of integers between 1 and 64 (eg row ids, trivial table)... E.g., {1, 5, 8} {1, 3, 5}? Can be done in one operation by a CPU: BitwiseOR( 10001001, 10101000)

Bitmaps and fast AND/OR operations Computing the union of two sets of integers between 1 and 64 (eg row ids, trivial table)... E.g., {1, 5, 8} {1, 3, 5}? Can be done in one operation by a CPU: BitwiseOR( 10001001, 10101000) Extend to sets from 1..N using N/64 operations.

Bitmap compression column x n 1 3 1 2... index bitmaps x=1 1 0 1 x=2 0 0 L x=3 0 0 1 0 0 1 0......... A column with n rows and L distinct values nl bits

Bitmap compression column x n 1 3 1 2... index bitmaps x=1 1 0 1 x=2 0 0 L x=3 0 0 1 0 0 1 0......... A column with n rows and L distinct values nl bits E.g., n = 10 6, L = 10 4 10 Gbits

Bitmap compression column x n 1 3 1 2... index bitmaps x=1 1 0 1 x=2 0 0 L x=3 0 0 1 0 0 1 0......... A column with n rows and L distinct values nl bits E.g., n = 10 6, L = 10 4 10 Gbits Uncompressed bitmaps are often impractical

Bitmap compression column x n 1 3 1 2... index bitmaps x=1 1 0 1 x=2 0 0 L x=3 0 0 1 0 0 1 0......... A column with n rows and L distinct values nl bits E.g., n = 10 6, L = 10 4 10 Gbits Uncompressed bitmaps are often impractical Moreover, bitmaps often contain long streams of zeroes...

Bitmap compression column x n 1 3 1 2... index bitmaps x=1 1 0 1 x=2 0 0 L x=3 0 0 1 0 0 1 0......... A column with n rows and L distinct values nl bits E.g., n = 10 6, L = 10 4 10 Gbits Uncompressed bitmaps are often impractical Moreover, bitmaps often contain long streams of zeroes... Logical operations over these zeroes is a waste of CPU cycles.

How to compress bitmaps? Must handle long streams of zeroes efficiently Run-length encoding? (RLE)

How to compress bitmaps? Must handle long streams of zeroes efficiently Run-length encoding? (RLE) RLE variants can focus on runs that align with machine-word boundaries.

How to compress bitmaps? Must handle long streams of zeroes efficiently Run-length encoding? (RLE) RLE variants can focus on runs that align with machine-word boundaries. Trade compression for speed.

How to compress bitmaps? Must handle long streams of zeroes efficiently Run-length encoding? (RLE) RLE variants can focus on runs that align with machine-word boundaries. Trade compression for speed. Our EWAH extends Wu et al. s word-aligned hybrid.

How to compress bitmaps? Must handle long streams of zeroes efficiently Run-length encoding? (RLE) RLE variants can focus on runs that align with machine-word boundaries. Trade compression for speed. Our EWAH extends Wu et al. s word-aligned hybrid. 0101000000000000 000... 000 000... 000 0011111111111100... dirty word, run of 2 clean 0 words, dirty word...

Computational and storage bounds n number of rows, c number of 1s per row;

Computational and storage bounds n number of rows, c number of 1s per row; Construction in time O(nc);

Computational and storage bounds n number of rows, c number of 1s per row; Construction in time O(nc); Total size of bitmaps is also in O(nc);

Computational and storage bounds n number of rows, c number of 1s per row; Construction in time O(nc); Total size of bitmaps is also in O(nc); Given two bitmaps B 1, B 2 of compressed size B 1 and B 2...

Computational and storage bounds n number of rows, c number of 1s per row; Construction in time O(nc); Total size of bitmaps is also in O(nc); Given two bitmaps B 1, B 2 of compressed size B 1 and B 2... AND, OR, XOR in time O( B 1 + B 2 ).

Computational and storage bounds n number of rows, c number of 1s per row; Construction in time O(nc); Total size of bitmaps is also in O(nc); Given two bitmaps B 1, B 2 of compressed size B 1 and B 2... AND, OR, XOR in time O( B 1 + B 2 ). Bounds do not depend on the number of bitmaps. Implementation scales to millions of bitmaps.

Improving compression by sorting the table RLE, BBC, WAH, EWAH are order-sensitive: they compress sorted data better;

Improving compression by sorting the table RLE, BBC, WAH, EWAH are order-sensitive: they compress sorted data better; But finding the best row ordering is NP-hard.

Improving compression by sorting the table RLE, BBC, WAH, EWAH are order-sensitive: they compress sorted data better; But finding the best row ordering is NP-hard. Lexicographic sorting is fast, even for very large tables.

Improving compression by sorting the table RLE, BBC, WAH, EWAH are order-sensitive: they compress sorted data better; But finding the best row ordering is NP-hard. Lexicographic sorting is fast, even for very large tables. easy: sort is a Unix staple.

Improving compression by sorting the table RLE, BBC, WAH, EWAH are order-sensitive: they compress sorted data better; But finding the best row ordering is NP-hard. Lexicographic sorting is fast, even for very large tables. easy: sort is a Unix staple. Substantial index-size reductions (often 2.5 times)

k-of-n encoding With L bitmaps, you can represent L values by mapping each value to one bitmap; 1-of-N 100000 010000 001000 000100 000010 100000 000001 value cat dog dish fish cow cat pony

k-of-n encoding 1-of-N 100000 010000 001000 000100 000010 100000 000001 2-of-N 1100 1010 1001 0110 0101 1100 0011 With L bitmaps, you can represent L values by mapping each value to one bitmap; Alternatively, ( you can represent L ) 2 = L(L 1)/2 values by mapping each value to a pair of bitmaps;

k-of-n encoding 1-of-N 100000 010000 001000 000100 000010 100000 000001 2-of-N 1100 1010 1001 0110 0101 1100 0011 With L bitmaps, you can represent L values by mapping each value to one bitmap; Alternatively, ( you can represent L ) 2 = L(L 1)/2 values by mapping each value to a pair of bitmaps; More generally, you can represent ( L k) values by mapping each value to a k-tuple of bitmaps;

k-of-n encoding 1-of-N 100000 010000 001000 000100 000010 100000 000001 2-of-N 1100 1010 1001 0110 0101 1100 0011 With L bitmaps, you can represent L values by mapping each value to one bitmap; Alternatively, ( you can represent L ) 2 = L(L 1)/2 values by mapping each value to a pair of bitmaps; More generally, you can represent ( L k) values by mapping each value to a k-tuple of bitmaps; At query time, you need to load k bitmaps in a look-up for one value;

k-of-n encoding 1-of-N 100000 010000 001000 000100 000010 100000 000001 2-of-N 1100 1010 1001 0110 0101 1100 0011 With L bitmaps, you can represent L values by mapping each value to one bitmap; Alternatively, ( you can represent L ) 2 = L(L 1)/2 values by mapping each value to a pair of bitmaps; More generally, you can represent ( L k) values by mapping each value to a k-tuple of bitmaps; At query time, you need to load k bitmaps in a look-up for one value; You trade query-time performance for fewer bitmaps;

k-of-n encoding 1-of-N 100000 010000 001000 000100 000010 100000 000001 2-of-N 1100 1010 1001 0110 0101 1100 0011 With L bitmaps, you can represent L values by mapping each value to one bitmap; Alternatively, ( you can represent L ) 2 = L(L 1)/2 values by mapping each value to a pair of bitmaps; More generally, you can represent ( L k) values by mapping each value to a k-tuple of bitmaps; At query time, you need to load k bitmaps in a look-up for one value; You trade query-time performance for fewer bitmaps; Often, fewer bitmaps translates into a smaller index, created faster.

Gray-code order, when k > 1 A Gray Code (GC) minimizes bit transitions: 00, 01, 11, 10

Gray-code order, when k > 1 A Gray Code (GC) minimizes bit transitions: 00, 01, 11, 10 Pinar et al. propose to sort whole index by < GC, Gray-code ordering. Practical?

Gray-code order, when k > 1 A Gray Code (GC) minimizes bit transitions: 00, 01, 11, 10 Pinar et al. propose to sort whole index by < GC, Gray-code ordering. Practical? We contribute an easy/fast way to achieve GC-like results using lexicographic sort.

Gray-code order, when k > 1 A Gray Code (GC) minimizes bit transitions: 00, 01, 11, 10 Pinar et al. propose to sort whole index by < GC, Gray-code ordering. Practical? We contribute an easy/fast way to achieve GC-like results using lexicographic sort. Empirical improvement in index size: typically 0 4%.

Gray-code order, when k > 1 A Gray Code (GC) minimizes bit transitions: 00, 01, 11, 10 Pinar et al. propose to sort whole index by < GC, Gray-code ordering. Practical? We contribute an easy/fast way to achieve GC-like results using lexicographic sort. Empirical improvement in index size: typically 0 4%. Paper has details.

Experimental environment Mac Pro with 2 dual-core CPUs 2 GiB RAM (no thrashing) GNU GCC 4.0.2 (C++) 32-bit binaries

Experimental environment Mac Pro with 2 dual-core CPUs 2 GiB RAM (no thrashing) GNU GCC 4.0.2 (C++) 32-bit binaries Source code under GPL: http://code.google.com/p/lemurbitmapindex/ (Linux and MacOS)

Experimental environment Mac Pro with 2 dual-core CPUs 2 GiB RAM (no thrashing) GNU GCC 4.0.2 (C++) 32-bit binaries Source code under GPL: http://code.google.com/p/lemurbitmapindex/ (Linux and MacOS) Mix of real and synthetic data: 1 up to 877 M rows, 22 GB, 4 M attributes. 2 experiments using 4 10 columns

Coding suggestions: choosing k 1 If k > 1, bitmaps are denser and a query processes k of them;

Coding suggestions: choosing k 1 If k > 1, bitmaps are denser and a query processes k of them; cost can grow with n (k 1)/k i (big jump from 1 to 2).

Coding suggestions: choosing k 1 If k > 1, bitmaps are denser and a query processes k of them; cost can grow with n (k 1)/k i (big jump from 1 to 2). 2 If k > 1, we (usually) get smaller indexes.

Coding suggestions: choosing k 1 If k > 1, bitmaps are denser and a query processes k of them; cost can grow with n (k 1)/k i (big jump from 1 to 2). 2 If k > 1, we (usually) get smaller indexes. Potentially high query-time penalty for k > 1, at best modest space gains.

Coding suggestions: choosing k 1 If k > 1, bitmaps are denser and a query processes k of them; cost can grow with n (k 1)/k i (big jump from 1 to 2). 2 If k > 1, we (usually) get smaller indexes. Potentially high query-time penalty for k > 1, at best modest space gains. Default choice of k Our index-construction algorithm handles the extremely sparse (k = 1) indexes nicely. k = 1 looks like a good choice.

When sorting, column order matters The first column(s) gain more from the sort (column 1 is primary sort key);

When sorting, column order matters The first column(s) gain more from the sort (column 1 is primary sort key); Conceptually, we may wish to reorder columns, eg swap columns 1 & 3.

When sorting, column order matters The first column(s) gain more from the sort (column 1 is primary sort key); Conceptually, we may wish to reorder columns, eg swap columns 1 & 3. Column order is crucial! Netflix: 24 column orderings index size 5.5e+08 5e+08 4.5e+08 4e+08 3.5e+08 3e+08 2.5e+08 2e+08 1.5e+08 1e+08 1234 1243 1324 1342 1423 1432 2134 2143 2314 2341 2413 2431 3124 3142 3214 3241 3412 3421 4123 4132 4213 4231 4312 4321 1-of-N encoding 4-of-N encoding column permutation

When sorting, column order matters The first column(s) gain more from the sort (column 1 is primary sort key); Conceptually, we may wish to reorder columns, eg swap columns 1 & 3. Column order is crucial! Finding the best ordering quickly remains open. Netflix: 24 column orderings index size 5.5e+08 5e+08 4.5e+08 4e+08 3.5e+08 3e+08 2.5e+08 2e+08 1.5e+08 1e+08 1234 1243 1324 1342 1423 1432 2134 2143 2314 2341 2413 2431 3124 3142 3214 3241 3412 3421 4123 4132 4213 4231 4312 4321 1-of-N encoding 4-of-N encoding column permutation

Progress toward choosing column order Paper models gain of putting a given column first. Idea: order columns greedily (by max gain).

Progress toward choosing column order Paper models gain of putting a given column first. Idea: order columns greedily (by max gain). Experimentally, this approach is not promising: the best orderings don t seem to depend on gain.

Progress toward choosing column order Paper models gain of putting a given column first. Idea: order columns greedily (by max gain). Experimentally, this approach is not promising: the best orderings don t seem to depend on gain. Factors: skews of columns number of distinct values k density of column s bitmaps

What usually works for dimension ordering?: k=1 For 1-of-N bitmaps, a density-based approach was okay:

What usually works for dimension ordering?: k=1 For 1-of-N bitmaps, a density-based approach was okay: Ordering rule, k = 1 : sparse but not too sparse Order columns by decreasing ( 1 min, 1 1/n ) i, where n i 4w 1 n i the number of distinct values in column i, w the word size. 50 100 150 200 250 300 distinct values in column

What usually works for dimension ordering?: k=1 For 1-of-N bitmaps, a density-based approach was okay: Ordering rule, k = 1 : sparse but not too sparse Order columns by decreasing ( 1 min, 1 1/n ) i, where n i 4w 1 n i the number of distinct values in column i, w the word size. 50 100 150 200 250 300 distinct values in column See 30 40% size reduction, merely knowing dimension sizes (n i ).

What usually works for dimension ordering?: k=1 For 1-of-N bitmaps, a density-based approach was okay: Ordering rule, k = 1 : sparse but not too sparse Order columns by decreasing ( 1 min, 1 1/n ) i, where n i 4w 1 n i the number of distinct values in column i, w the word size. 50 100 150 200 250 300 distinct values in column See 30 40% size reduction, merely knowing dimension sizes (n i ). See also [Canahuate et al., 2006] for related work.

What usually works for dimension ordering?: k=1 For 1-of-N bitmaps, a density-based approach was okay: Ordering rule, k = 1 : sparse but not too sparse Order columns by decreasing ( 1 min, 1 1/n ) i, where n i 4w 1 n i the number of distinct values in column i, w the word size. 50 100 150 200 250 300 distinct values in column See 30 40% size reduction, merely knowing dimension sizes (n i ). See also [Canahuate et al., 2006] for related work. Situation worse for k > 1. Details

Future directions Need better mathematical modelling of bitmap compressed size in sorted tables;

Future directions Need better mathematical modelling of bitmap compressed size in sorted tables; Study the effect of word length (16, 32, 64, 128 bits);

Future directions Need better mathematical modelling of bitmap compressed size in sorted tables; Study the effect of word length (16, 32, 64, 128 bits); Apply to Column-oriented DBMS [Stonebraker et al., 2005];

Future directions Need better mathematical modelling of bitmap compressed size in sorted tables; Study the effect of word length (16, 32, 64, 128 bits); Apply to Column-oriented DBMS [Stonebraker et al., 2005]; Consider encodings that can efficiently support range queries [Chan and Ioannidis, 1999].

Questions??

Canahuate, G., Ferhatosmanoglu, H., and Pinar, A. (2006). Improving bitmap index compression by data reorganization. http: //hpcrd.lbl.gov/~apinar/papers/tkde06.pdf (checked 2008-05-30). Chan, C. Y. and Ioannidis, Y. E. (1999). An efficient bitmap encoding scheme for selection queries. In SIGMOD 99, pages 215 226. Pinar, A., Tao, T., and Ferhatosmanoglu, H. (2005). Compressing bitmap indices by data reorganization. In ICDE 05, pages 310 321. Sharma, V. (2005). Bitmap index vs. b-tree index: Which and when? online: http://www.oracle.com/technology/pub/ articles/sharma_indexes.html. Stonebraker, M., Abadi, D. J., Batkin, A., Chen, X., Cherniack, M., Ferreira, M., Lau, E., Lin, A., Madden, S.,

O Neil, E., O Neil, P., Rasin, A., Tran, N., and Zdonik, S. (2005). C-store: a column-oriented dbms. In VLDB 05, pages 553 564. Wu, K., Otoo, E. J., and Shoshani, A. (2006). Optimizing bitmap indices with efficient compression. ACM Transactions on Database Systems, 31(1):1 38.

What usually works for dimension ordering?: k > 1 Density formula (n i k n i ) recommends poorly when k > 1. Our experiments on synthetic data give some guidance:

What usually works for dimension ordering?: k > 1 Density formula (n i k n i ) recommends poorly when k > 1. Our experiments on synthetic data give some guidance: When k > 1, order columns by 1 descending skew 2 descending size (And do the reverse when k = 1.)

What usually works for dimension ordering?: k > 1 Density formula (n i k n i ) recommends poorly when k > 1. Our experiments on synthetic data give some guidance: When k > 1, order columns by 1 descending skew 2 descending size (And do the reverse when k = 1.) Open issues, k > 1 1 How do we balance skew & size factors?

What usually works for dimension ordering?: k > 1 Density formula (n i k n i ) recommends poorly when k > 1. Our experiments on synthetic data give some guidance: When k > 1, order columns by 1 descending skew 2 descending size (And do the reverse when k = 1.) Open issues, k > 1 1 How do we balance skew & size factors? 2 What other properties of the histograms are needed?

Gray-code order Lex. order 0 1 1 0 1 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 1 1 1 1 1 1 1 Gray-code 0 1 1 0 1 1 1 1 0 1 1 0 1 1 1 1 1 1 1 1 1 1 0 1 1 0 1 Gray-code (GC) order is an alternative to lexicographical order (defined only for bit arrays);

Gray-code order Lex. order 0 1 1 0 1 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 1 1 1 1 1 1 1 Gray-code 0 1 1 0 1 1 1 1 0 1 1 0 1 1 1 1 1 1 1 1 1 1 0 1 1 0 1 Gray-code (GC) order is an alternative to lexicographical order (defined only for bit arrays); May improve compression more than lex. sort (k > 1);

Gray-code order Lex. order 0 1 1 0 1 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 1 1 1 1 1 1 1 Gray-code 0 1 1 0 1 1 1 1 0 1 1 0 1 1 1 1 1 1 1 1 1 1 0 1 1 0 1 Gray-code (GC) order is an alternative to lexicographical order (defined only for bit arrays); May improve compression more than lex. sort (k > 1); [Pinar et al., 2005] process a materialized bitmap index.

Gray-code order Lex. order 0 1 1 0 1 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 1 1 1 1 1 1 1 Gray-code 0 1 1 0 1 1 1 1 0 1 1 0 1 1 1 1 1 1 1 1 1 1 0 1 1 0 1 Gray-code (GC) order is an alternative to lexicographical order (defined only for bit arrays); May improve compression more than lex. sort (k > 1); [Pinar et al., 2005] process a materialized bitmap index. Slow, if uncompressed index does not fit in RAM.

Gray-code order Lex. order 0 1 1 0 1 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 1 1 1 1 1 1 1 Gray-code 0 1 1 0 1 1 1 1 0 1 1 0 1 1 1 1 1 1 1 1 1 1 0 1 1 0 1 Gray-code (GC) order is an alternative to lexicographical order (defined only for bit arrays); May improve compression more than lex. sort (k > 1); [Pinar et al., 2005] process a materialized bitmap index. Slow, if uncompressed index does not fit in RAM. GC order is not supported by DBMSes or Unix utilities.

Gray-code sorting, cheaply Size improvement is small (usually < 4%), but it s essentially free: 1 What Pinar et al. do: expensive GC sort after encoding eg: [Tax, Cat, Girl, Cat] sort([1100, 0110, 1001, 0110]);

Gray-code sorting, cheaply Size improvement is small (usually < 4%), but it s essentially free: 1 What Pinar et al. do: expensive GC sort after encoding eg: [Tax, Cat, Girl, Cat] sort([1100, 0110, 1001, 0110]); 2 Instead, sort the table lexicographically; eg: [Tax, Cat, Girl, Cat] [Cat, Cat, Girl, Tax]

Gray-code sorting, cheaply Size improvement is small (usually < 4%), but it s essentially free: 1 What Pinar et al. do: expensive GC sort after encoding eg: [Tax, Cat, Girl, Cat] sort([1100, 0110, 1001, 0110]); 2 Instead, sort the table lexicographically; eg: [Tax, Cat, Girl, Cat] [Cat, Cat, Girl, Tax] 3 Map ordered values to k-tuples of bitmaps ordered as Gray codes: Cat: 0011, Dog: 0110, Girl: 0101, Tax: 1100; Lex ascending sequence: Cat, Dog, Girl, Tax. GC ascending sequence: 0011, 0110, 0101, 1100 for codes

Gray-code sorting, cheaply Size improvement is small (usually < 4%), but it s essentially free: 1 What Pinar et al. do: expensive GC sort after encoding eg: [Tax, Cat, Girl, Cat] sort([1100, 0110, 1001, 0110]); 2 Instead, sort the table lexicographically; eg: [Tax, Cat, Girl, Cat] [Cat, Cat, Girl, Tax] 3 Map ordered values to k-tuples of bitmaps ordered as Gray codes: Cat: 0011, Dog: 0110, Girl: 0101, Tax: 1100; Lex ascending sequence: Cat, Dog, Girl, Tax. GC ascending sequence: 0011, 0110, 0101, 1100 for codes eg: [Cat, Cat, Girl, Tax] [0011, 0011, 0101, 1100] (generates a GC-sorted result without expensive GC sorting).

Gray-code sorting, cheaply Size improvement is small (usually < 4%), but it s essentially free: 1 What Pinar et al. do: expensive GC sort after encoding eg: [Tax, Cat, Girl, Cat] sort([1100, 0110, 1001, 0110]); 2 Instead, sort the table lexicographically; eg: [Tax, Cat, Girl, Cat] [Cat, Cat, Girl, Tax] 3 Map ordered values to k-tuples of bitmaps ordered as Gray codes: Cat: 0011, Dog: 0110, Girl: 0101, Tax: 1100; Lex ascending sequence: Cat, Dog, Girl, Tax. GC ascending sequence: 0011, 0110, 0101, 1100 for codes eg: [Cat, Cat, Girl, Tax] [0011, 0011, 0101, 1100] (generates a GC-sorted result without expensive GC sorting). 4 Easily extended for > 1 columns.

Gray-code sorting, cheaply Size improvement is small (usually < 4%), but it s essentially free: 1 What Pinar et al. do: expensive GC sort after encoding eg: [Tax, Cat, Girl, Cat] sort([1100, 0110, 1001, 0110]); 2 Instead, sort the table lexicographically; eg: [Tax, Cat, Girl, Cat] [Cat, Cat, Girl, Tax] 3 Map ordered values to k-tuples of bitmaps ordered as Gray codes: Cat: 0011, Dog: 0110, Girl: 0101, Tax: 1100; Lex ascending sequence: Cat, Dog, Girl, Tax. GC ascending sequence: 0011, 0110, 0101, 1100 for codes eg: [Cat, Cat, Girl, Tax] [0011, 0011, 0101, 1100] (generates a GC-sorted result without expensive GC sorting). 4 Easily extended for > 1 columns. In our tests, this is as good as a Gray-code bitmap index sort [Pinar et al., 2005], but technically much easier.