C-Store: A Column-oriented DBMS
2005 · paper · Computer science
Presents the design of C-Store, a read-optimized relational database that stores data by column rather than by row. Preliminary results on a subset of TPC-H show it substantially faster than popular commercial products.
Checked: PDF from vldb.org, fetched 4 Oct 2026. Page numbers are those of that PDF.
4 findings
Substance Summary says C-Store is "21 times faster than the commercial column-store in the space-constrained case", but the first timing table gives a mean per-query Column Store/C-Store ratio of about 16.2 (ratio of totals about 6.5).
- p. 11 Section 9, summary paragraph after second performance table
21 times faster than the commercial column-
- p. 11 Section 9, first performance table, Column Store column
2.24
- p. 11 first performance table
Q1 0.03 6.80 2.24
- p. 11 Summary paragraph
21 times faster than the commercial column-store in the space-constrained case
Only the authors can say what is right here.
Judge's note: Read both timing tables and the summary paragraph on the page 11 image. The mean of per-query ratios reproduces the paper's row-store figures (164.6 against printed 164; 6.45 against printed 6.4), so that is evidently the method used. Applied to the column-store column of the first table it gives 16.2, and the ratio of summed times gives 6.5; neither reaches 21. The averaging method is not stated anywhere in the text, so only the authors can say which number is intended.
Second check: another model agreed
Report a problem with this finding
Substance Summary says "C-Store is on average 16.5 times faster than the commercial column-store" in the unconstrained-space case, but the second timing table gives a mean per-query Column Store/C-Store ratio of about 14.9 (ratio of totals about 4.6).
- p. 11 Section 9, summary paragraph
C-Store is on average 16.5 times faster than the
- p. 11 Section 9, second performance table, Column Store column
2.34
- p. 11 Summary paragraph
C-Store is on average 16.5 times faster than the commercial column-store
- p. 11 Section 9 summary
16.5 times faster than the commercial column-store
Only the authors can say what is right here.
Judge's note: Read the second timing table and the summary on the page 11 image. The mean of per-query ratios gives 6.45 for the row store, matching the printed 6.4, but 14.9 for the column store against the printed 16.5. The ratio of summed times gives 4.6. The printed 16.5 is closer to the first table's column-store mean (16.2) but matches neither table. The averaging method is not stated, so this is a query for the authors.
Second check: another model agreed
Report a problem with this finding
Substance Summary says "the column-store requires 1.83 times the space", but the second disk-usage table ("1.987 GB 11.900 GB 4.090 GB") gives 4.090/1.987 = about 2.06.
- p. 11 Section 9, summary paragraph
1.83 times the space
- p. 11 Section 9, second disk-usage table
4.090 GB
- p. 11 Section 9 summary
the column-store requires 1.83 times the space
- p. 11 space table (materialized views case)
1.987 GB 11.900 GB 4.090 GB
Only the authors can say what is right here.
Judge's note: Read the second space table and the summary on the page 11 image. The row-store statement in the same passage ("6 times the space") matches its table entry (11.900/1.987 = 5.99). The column-store ratio is 2.06, not 1.83. Other baselines do not give 1.83 either: 4.090/2.650 = 1.54 and 4.090/2.7 = 1.51. I found no statement in the text that explains a different baseline. Either the ratio or the table entry is off; the authors must say which.
Second check: another model agreed
Report a problem with this finding
Reference or label Section 6.3.1 defines "a sort key K and a key range R" but then uses K for the range: "covers the key range K" and "AND sort_key in K"; R is never used again.
- p. 8 Section 6.3.1, first paragraph
key K and a key range R on a recovering site r
- p. 8 Section 6.3.1, second paragraph
key range K with each segment having
- p. 8 Section 6.3.1, recovery query
AND sort_key in K
- p. 8 Sec 6.3.1
a projection with a sort key K and a key range R
Judge's note: Read on the page 8 image. K is introduced as the sort key and R as the key range. The next paragraph says "key range K" and the query predicate is "sort_key in K". Both only make sense with the range R, so the symbol is mislabelled. The reuse of K for K-safety elsewhere is a separate, harmless overloading.
Second check: another model agreed
Report a problem with this finding
13 minor (typos and the like; most checked by the judge only)
Wording Type 2 bitmaps are "run length encoded to save space" in Section 3.1 but "stored as a delta-encoded bitmaps, with one bitmap per value" in Section 8.2; the latter also has an agreement slip ("a ... bitmaps").
- p. 5 Section 3.1, Type 2
length encoded to save space
- p. 9 Section 8.2, second paragraph
delta-encoded bitmaps, with one bitmap per value
- p. 5 Sec 3.1 Type 2
it is run length encoded to save space
- p. 9 Sec 8.2
stored as a delta-encoded bitmaps, with one bitmap per value
Judge's note: Both passages read on the page 5 and page 9 images. Section 3.1 uses run-length encoding for Type 2 and reserves "delta" for Type 3. Section 8.2 recaps Type 2 as delta-encoded. Run-length coding of a sparse bitmap could loosely be called delta coding, so either form may be intended; this is a terminology inconsistency, not a definite error.
Second check: another model agreed
Report a problem with this finding
Wording The recovery query's WHERE clause mixes AND and OR without parentheses: "AND deletion_epoch = 0 OR deletion_epoch >= LWM AND sort_key in K"; under standard SQL precedence this is not the grouping the indentation suggests.
- p. 8 Section 6.3.1, recovery query
OR deletion_epoch >= LWM
Judge's note: Read on the page 8 image. The OR line is indented under "deletion_epoch = 0", which signals the intended grouping (deletion_epoch = 0 OR deletion_epoch >= LWM), but no parentheses are printed. Section 2 says the language is SQL "with standard SQL semantics", under which AND binds tighter than OR. The query is offered schematically ("queries of the form"), so this is a minor ambiguity.
Second check: another model agreed
Report a problem with this finding
Wording Section 8.2 says "As will be shown in Section 9, the ability to process compressed data is the key to the performance benefits of C-Store", but Section 9 only lists operating on compressed data as one of four asserted reasons, with no measurement isolating it.
- p. 9 Section 8.2, second paragraph
shown in Section 9, the ability to process compressed data
- p. 11 Section 9, bullet list of reasons
representation – mitigates the storage barrier problem of
Judge's note: Read Section 8.2 on the page 9 image and Section 9 on the page 10 and 11 images. Section 9 reports end-to-end query times and a bullet list of four "main reasons", one of which is "Query operators operate on compressed representation". Nothing there shows it to be "the key". The forward pointer overstates what Section 9 contains; it is a wording point only.
Second check: another model agreed
Report a problem with this finding
Typo Subject-verb disagreement: "it is their combination in a real system that make C-Store interesting and unique" (should be "makes").
- p. 3 Section 1, paragraph after the numbered list
system that make C-Store interesting and unique
Judge's note: Read on the page 3 image, end of Section 1 list paragraph. The subject is the singular "combination", and the verb is printed as "make".
Second check: none (judge only)
Report a problem with this finding
Typo Duplicated word: "Again, a densepack B-tree tree at the block-level can be used to index these coded objects."
- p. 5 Section 3.1, Type 3
densepack B-tree tree at the block-level
- p. 5 3.1 Type 3 encoding
a densepack B-tree tree at the block-level
- p. 5
VSAM04]. Again, a densepack B-tree tree at the block-level
Judge's note: Visible on the page 5 image, right column, Type 3 paragraph. The word "tree" is printed twice; it is not an extraction artefact.
Second check: code check
Report a problem with this finding
Typo Unclosed parenthesis: "its ordering (i.e., is the column ordered by values in that column (self-order) or by corresponding values of some other column in the same projection (foreign-order), and the proportion of distinct values it contains."
- p. 5 Section 3.1, first paragraph
other column in the same projection (foreign-order), and
Judge's note: Read on the page 5 image, Section 3.1 first paragraph. The parenthesis opened at "(i.e.," is never closed; only the nested "(self-order)" and "(foreign-order)" are closed.
Second check: none (judge only)
Report a problem with this finding
Typo Missing full stop at the end of the paragraph: "Similar issues are addressed in [PAPA04]".
- p. 5 Section 2, penultimate paragraph
issues are addressed in [PAPA04]
Judge's note: On the page 5 image the paragraph ends with "[PAPA04]" and no terminal period before the next paragraph, "We now turn to...".
Second check: none (judge only)
Report a problem with this finding
Typo Article error: "it sends a end of epoch message to each site" (should be "an end of epoch message").
- p. 7 Section 6.1.1, first paragraph
it sends a end of epoch message to each site
- p. 7 6.1.1
it sends a end of epoch message
Judge's note: Read on the page 7 image, Section 6.1.1. The text prints "a end of epoch" with "end of epoch" in italics; the later phrase "an epoch complete message" is correct.
Second check: none (judge only)
Report a problem with this finding
Typo Missing verb in operator list item 4: "Project equivalent to the projection operator of the relational algebra" (cf. item 2, "Select is equivalent to...").
- p. 9 8.1 item 4
Project equivalent to the projection operator
Judge's note: Read on the page 9 image, Section 8.1. Item 4 lacks "is", while the parallel item 2 has it.
Second check: none (judge only)
Report a problem with this finding
Typo Q7 reads "FROM lineitem, orders, customers" but the schema defines "CREATE TABLE CUSTOMER"; the prose also names the "order" table, which is defined as ORDERS.
- p. 10 Section 9, Q7 SQL
FROM lineitem, orders, customers
- p. 10 Section 9, schema
CREATE TABLE CUSTOMER (
- p. 10 Section 9, text before schema
lineitem, order,
Judge's note: Read on the page 10 image. The schema creates CUSTOMER (singular) and ORDERS. Q7 selects from "customers" (plural), and the prose says "lineitem, order, and customer tables". These are table-name slips with an evident fix.
Second check: none (judge only)
Report a problem with this finding
Typo Number mismatch: "These schema were tuned individually for the capabilities of each system" (preceding sentence uses "schemas").
- p. 10 Section 9
These schema were tuned individually
Judge's note: Read on the page 10 image, right column, after Q7. A plural determiner and verb are used with the singular "schema"; the preceding sentence has "schemas".
Second check: none (judge only)
Report a problem with this finding
Typo The same publisher is spelled two ways in the reference list: "Morgan Kaufman, 1992" in [GRAY92] and "Morgan-Kaufmann Publishers , 2000" in [WEST00].
- p. 12 References, [GRAY92]
Morgan Kaufman, 1992
- p. 12 References, [WEST00]
Morgan-Kaufmann Publishers , 2000
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: the publisher's correct name is "Morgan Kaufmann" (double n, no hyphen), which cannot be checked from the files. The inconsistency between the two entries is visible on the page 12 image; [WEST00] also has a stray space before the comma.
Second check: none (judge only)
Report a problem with this finding
Typo [RAMA02] prints "Ravishankar Ramamurthy, David Dewitt. Qi Su: A Case for Fractured Mirrors", with a full stop where a comma between authors belongs; the surname is "Dewitt" in the references but "DeWitt" in the acknowledgements.
- p. 12 References, [RAMA02]
Ravishankar Ramamurthy, David Dewitt. Qi Su: A Case
Judge's note: Confirmed on the page 12 image. Other entries separate authors with commas and use a colon before the title (for example [ROTH93]), so the full stop after "Dewitt" is a punctuation slip. "Dewitt" appears in [DEWI90], [DEWI92] and [RAMA02], against "David DeWitt" in the acknowledgements.
Second check: none (judge only)