1987 IEEE Third International Conference on Data Engineering 1987
DOI: 10.1109/icde.1987.7272433
|View full text |Cite
|
Sign up to set email alerts
|

A query processing strategy for the decomposed storage model

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
3
1
1

Citation Types

0
24
0
1

Year Published

1995
1995
2018
2018

Publication Types

Select...
6
1
1

Relationship

0
8

Authors

Journals

citations
Cited by 42 publications
(25 citation statements)
references
References 9 publications
0
24
0
1
Order By: Relevance
“…In this paper, we revisit this literature on compression in the context of column-oriented database systems [28,9,10,18,21,1,19]. A column-oriented database system (or "column-store") is one in which each attribute is stored in a separate column, such that successive values of that attribute are stored consecutively on disk.…”
Section: Introductionmentioning
confidence: 99%
“…In this paper, we revisit this literature on compression in the context of column-oriented database systems [28,9,10,18,21,1,19]. A column-oriented database system (or "column-store") is one in which each attribute is stored in a separate column, such that successive values of that attribute are stored consecutively on disk.…”
Section: Introductionmentioning
confidence: 99%
“…The practical conclusions from this work, reported in [VKC86] and cited in [KCJ+87], is (1) that DSM with join indexes provides better retrieval performance than NSM when the number of retrieved attributes is low or the number of retrieved records is medium to high, while NSM provides better retrieval performance when the number of retrieved attributes is high and the number of retrieved records is low, and (2) that the performance of single attribute modification is the same for both DSM and NSM, while NSM provides better record insert/delete performance. This is an approach which is similar to those used in MonetDB [MBK00a,MBK00b] and in Cantor [Sve82], with the following main differences: (1) DSM provides two predefined join indices for each attribute, one clustered on each of the two attributes (attribute value, TID), while Cantor and MonetDB both use indices which are created as needed during query evaluation; (2) Cantor stores these indices using Run-Length-Encoding (RLE) compression; MonetDB introduces a novel radix cluster algorithm for hash join; (3) although potentially important, parallelism has not been presented as a key design issue for MonetDB, nor was it one for Cantor; (4) the algorithms used in MonetDB and Cantor were both presented as simple two-way joins, corresponding mainly to the composition phase in the DSM algorithm, which is presented as an m-way join.…”
Section: Transposed Files and The Decomposed Storage Modelmentioning
confidence: 99%
“…While the authors of [CK85] [KCJ+87], the DSM further assumes that two copies of each binary relation are stored, one clustered (i.e., sorted or hashed with an index) on each of the two attributes (TID, value). The authors of [CK85] conclude that there seems to be a general consensus among the database community that the conventional N-ary Storage Model (NSM) is better.…”
Section: Transposed Files and The Decomposed Storage Modelmentioning
confidence: 99%
See 1 more Smart Citation
“…Recommending a physical configuration for a given workload has been widely studied since 1987 [16]. Most of the existing works [17][18][19][20][21][22][23] propose effective methods to estimate the cost of a given workload over candidate physical configurations.…”
Section: Related Workmentioning
confidence: 99%