VLDB 2026 Research / reviewers in the wild / expert
David Sharpe
dblp:53/26
· DBLP profile ↗
3ranked-venue papers
0as first author
0since 2021 · last 2014
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Databases, data management, data science and information retrieval · 2Software engineering, systems software and programming languages · 1
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Databases, data mining, and information retrieval
2 papers |
Query processing and optimization · 59% Indexing and storage engines · 41% |
Topics — the 10 heaviest of 10, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Query processing and optimization › join processing › join algorithms
hash join |
0.2 | 1 | 2014 | Memory-Efficient Hash Joins · Proc. VLDB Endow. 2014 |
Query processing and optimization
join processing |
0.2 | 1 | 2014 | Memory-Efficient Hash Joins · Proc. VLDB Endow. 2014 |
Indexing and storage engines
column store |
0.2 | 1 | 2013 | DB2 with BLU Acceleration: So Much More than Just a Column Store · Proc. VLDB Endow. 2013 |
Query processing and optimization
compressed data processing |
0.2 | 1 | 2013 | DB2 with BLU Acceleration: So Much More than Just a Column Store · Proc. VLDB Endow. 2013 |
Indexing and storage engines › data compression
dictionary compression |
0.2 | 1 | 2013 | DB2 with BLU Acceleration: So Much More than Just a Column Store · Proc. VLDB Endow. 2013 |
Query processing and optimization › query execution
in-memory query processing |
0.2 | 1 | 2013 | DB2 with BLU Acceleration: So Much More than Just a Column Store · Proc. VLDB Endow. 2013 |
Indexing and storage engines › column store
main-memory column store |
0.2 | 1 | 2013 | DB2 with BLU Acceleration: So Much More than Just a Column Store · Proc. VLDB Endow. 2013 |
Query processing and optimization › query execution › hardware-accelerated query processing
SIMD query processing |
0.2 | 1 | 2013 | DB2 with BLU Acceleration: So Much More than Just a Column Store · Proc. VLDB Endow. 2013 |
Indexing and storage engines
hash index |
0.1 | 1 | 2014 | Memory-Efficient Hash Joins · Proc. VLDB Endow. 2014 |
Indexing and storage engines
buffer management |
0.0 | 1 | 2013 | DB2 with BLU Acceleration: So Much More than Just a Column Store · Proc. VLDB Endow. 2013 |
Methods — techniques the papers use, named apart from their topics
partitioning · 0.2linear probing · 0.2bloom filter · 0.2prefetching · 0.2late materialization · 0.2frequency-based dictionary compression · 0.2SIMD · 0.2
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2014 | Memory-Efficient Hash JoinsabstractWe present new hash tables for joins, and a hash join based on them, that consumes far less memory and is usually faster than recently published in-memory joins. Our hash join is not restricted to outer tables that fit wholly in memory. Key to this hash join is a new concise hash table (CHT), a linear probing hash table that has 100% fill factor, and uses a sparse bitmap with embedded population counts to almost entirely avoid collisions. This bitmap also serves as a Bloom filter for use in multi-table joins. We study the random access characteristics of hash joins, and renew the case for non-partitioned hash joins. We introduce a variant of partitioned joins in which only the build is partitioned, but the probe is not, as this is more efficient for large outer tables than traditional partitioned joins. This also avoids partitioning costs during the probe, while at the same time allowing parallel build without latching overheads. Additionally, we present a variant of CHT, called a concise array table (CAT), that can be used when the key domain is moderately dense. CAT is collision-free and avoids storing join keys in the hash table. We perform a detailed comparison of CHT and CAT against leading in-memory hash joins. Our experiments show that we can reduce the memory usage by one to three orders of magnitude, while also being competitive in performance. Ron Barber, Guy M. Lohman, Ippokratis Pandis, Vijayshankar Raman, Richard Sidle, Gopi K. Attaluri, Naresh Chainani, Sam Lightstone, David Sharpe |
Proc. VLDB Endow. | 9 |
| 2013 | DB2 with BLU Acceleration: So Much More than Just a Column StoreabstractDB2 with BLU Acceleration deeply integrates innovative new techniques for defining and processing column-organized tables that speed read-mostly Business Intelligence queries by 10 to 50 times and improve compression by 3 to 10 times, compared to traditional row-organized tables, without the complexity of defining indexes or materialized views on those tables. But DB2 BLU is much more than just a column store. Exploiting frequency-based dictionary compression and main-memory query processing technology from the Blink project at IBM Research - Almaden, DB2 BLU performs most SQL operations - predicate application (even range predicates and IN-lists), joins, and grouping - on the compressed values, which can be packed bit-aligned so densely that multiple values fit in a register and can be processed simultaneously via SIMD (single-instruction, multipledata) instructions. Designed and built from the ground up to exploit modern multi-core processors, DB2 BLU's hardware-conscious algorithms are carefully engineered to maximize parallelism by using novel data structures that need little latching, and to minimize data-cache and instruction-cache misses. Though DB2 BLU is optimized for in-memory processing, database size is not limited by the size of main memory. Fine-grained synopses, late materialization, and a new probabilistic buffer pool protocol for scans minimize disk I/Os, while aggressive prefetching reduces I/O stalls. Full integration with DB2 ensures that DB2 with BLU Acceleration benefits from the full functionality and robust utilities of a mature product, while still enjoying order-of-magnitude performance gains from revolutionary technology without even having to change the SQL, and can mix column-organized and row-organized tables in the same tablespace and even within the same query. Vijayshankar Raman, Gopi K. Attaluri, Ron Barber, Naresh Chainani, David Kalmuk, Vincent KulandaiSamy, Jens Leenstra, Sam Lightstone, Shaorong Liu, Guy M. Lohman, Tim Malkemus, René Müller 0001, Ippokratis Pandis, Berni Schiefer, David Sharpe, Richard Sidle, Adam J. Storm |
Proc. VLDB Endow. | 15 |
| 1998 | An Approach for Decomposing N-Ary Data RelationshipsabstractOne of the most significant challenges in the use of entity relationship data models is in deciding whether to use a single relationship between several entities or a set of simpler relationships to represent a complex association. A practical eight-step approach is presented for analysis of n-ary relationships and decomposition into simpler relationships where appropriate. Relational database design concepts form the basis for this approach. An extended specification of cardinality constraints is used to support the decomposition approach and to ensure applicability to a variety of modeling styles. This approach defines a fundamental analysis skill for data modeling practitioners. © 1998 John Wiley & Sons, Ltd. Andrew J. McAllister, David Sharpe |
Softw. Pract. Exp. | 2 |