Presto: SQL on Everything
Proceedings - International Conference on Data Engineering, 2019 · paper · Computer science
Describes Presto, an open source distributed SQL query engine supporting much of Facebook's analytics, from sub-second reporting to multi-hour ETL jobs. It covers use cases, architecture, a connector API for many data sources, and performance results for its design decisions.
Checked: PDF from trino.io, fetched 4 Oct 2026. Page numbers are those of that PDF.
2 findings
Reference or label Reference [1] gives no author: "[1] Volcano - An Extensible and Parallel Query Evaluation System. IEEE Transactions on Knowledge and Data Engineering, 6(1):120–135, 1994."
- p. 12 References [1]
[1] Volcano - An Extensible and Parallel Query Evaluation System.
- p. 12 References, entry [1]
[1] Volcano - An Extensible and Parallel Query Evaluation System. IEEE
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: that the TKDE 1994 Volcano paper was written by G. Graefe. I checked the reference list on p.12 (both crops). Entry [1] starts directly with the title. Neighbouring journal and conference entries such as [3], [4] and [5] list their authors. [2] is an ISO standard, so it legitimately has no personal author. The entry is therefore incomplete as published, and only the authors can confirm the intended author field.
Second check: another model agreed
Report a problem with this finding
Wording Sec. IV-D1 says "This greatly improves memory efficiency for the Batch Analytics use case." No 'Batch Analytics' use case is defined; the defined use case is 'Batch ETL'.
- p. 5 Section IV-D1 Stage Scheduling
memory efficiency for the Batch Analytics use case
- p. 5 IV-D1 Stage Scheduling
This greatly improves memory efficiency for the Batch Analytics use case.
- p. 5 IV-D1 Stage Scheduling
memory efficiency for the Batch
Judge's note: Checked p5. Sec. II defines four use cases: Interactive Analytics, Batch ETL, A/B Testing and Developer/Advertiser Analytics. Table I and the other mentions use 'Batch ETL'.
Second check: another model agreed
Report a problem with this finding
15 minor (typos and the like; most checked by the judge only)
Wording The A/B Testing latency is given as "interactive latency (∼5-30s)" in Sec. II-C but as "1 sec - 25 sec" in Table I.
- p. 2 Section II-C A/B Testing
results at interactive latency (∼5-30s)
- p. 11 Table I, A/B Testing row
1 sec - 25 sec
- p. 2 Section II-C A/B Testing
interactive latency (∼5-30s)
Only the authors can say what is right here.
Judge's note: Both ranges are on the page images (p2 right column; p11 Table I). Sec. II-C describes a requirement for slice-and-dice queries and Table I gives a query duration, so they may be different quantities. For the other use cases, though, the Sec. II figures match Table I (Dev/Advertiser 50ms-5s; Interactive 50-100 queries). Fig. 7 (p10) shows about half of A/B Testing queries finishing in about 1 s. The authors should say which range applies.
Second check: another model agreed
Report a problem with this finding
Wording Sec. VI-B gives "strict latency requirements (20-100ms)" for web use cases, while Sec. II-D gives "very strict query latency requirements (∼50ms-5s)" and Table I gives "50 ms - 5 sec" for Developer/Advertiser Analytics.
- p. 10 Section VI-B Flexibility
strict latency requirements (20- 100ms)
- p. 2 Section II-D
requirements (∼50ms-5s)
- p. 11 Table I, Developer/Advertiser Analytics row
50 ms - 5 sec
- p. 2 II-D
very strict query latency requirements (∼50ms-5s)
Only the authors can say what is right here.
Judge's note: Checked p10, p2 and p11. Both passages call the figure a requirement, but the ranges differ at both ends. Sec. VI-B may mean typical observed latency rather than the full range; the authors should clarify.
Second check: another model agreed
Report a problem with this finding
Wording The query is "FROM orders LEFT JOIN lineitem", but Fig. 2 draws Filter/Scan[lineitem] as the left input of "LeftJoin [ON orderkey]" and Scan[orders] as the right input. Figs. 3–4 keep this order: lineitem is the probe side (ScanFilterHash→LookupJoin) and orders is the build side.
- p. 3 SQL example, Section IV-B3
FROM orders LEFT JOIN lineitem
- p. 3 Fig. 2
LeftJoin [ON orderkey]
Only the authors can say what is right here.
Judge's note: Checked on p3 (SQL and Fig. 2) and on p4–5 (Figs. 3 and 4). The child order in Fig. 2 could be a drawing convention. However, Figs. 3/4 carry the probe and build roles forward, and the filtered lineitem side is the probe. That fits 'lineitem LEFT JOIN orders' rather than the query as written. Because the WHERE on a lineitem column effectively turns the outer join into an inner join, the result may be unaffected. Even so, the figure labels do not match the query as printed.
Second check: another model agreed
Report a problem with this finding
Wording In the query, "WHERE discount = 0" applies after "orders LEFT JOIN lineitem". Fig. 2, which the text describes as a plan of 'purely logical' nodes, instead shows "Filter [discount=0]" below the join on the lineitem input.
- p. 3 SQL example and Section IV-B3
WHERE discount = 0
- p. 3 Fig. 2
Filter [discount=0]
Only the authors can say what is right here.
Judge's note: Checked p3. In the query as written, the WHERE removes null-extended orders. Filtering lineitem before a LEFT JOIN that preserves orders would keep those rows, so the two placements are not equivalent unless the join is also converted or swapped (compare C002). The text says the planner produces purely logical nodes before optimization, but the figure shows a pushed-down filter. This may be a deliberate simplification; the authors should clarify.
Second check: another model agreed
Report a problem with this finding
Wording Sec. III says the Connector API "is composed of four parts: the Metadata API, Data Location API, Data Source API, and Data Sink API". Secs. IV-C1 and IV-D2 then refer to a "connector Data Layout API" / "Connector Data Layout API", which is not one of the four.
- p. 3 Section III
API, which is composed of four parts: the Metadata API, Data Location API, Data Source API, and Data Sink API
- p. 3 Section IV-C1
connector Data Layout API
- p. 5 Section IV-D2 Leaf Stages
Connector Data Layout API
Only the authors can say what is right here.
Judge's note: Checked p3 (Sec. III, Sec. IV-C1), p5 (Leaf Stages) and Fig. 1 on p2, which labels a 'Data Location API'. The paper never says how the Data Layout API relates to the four listed parts.
Second check: another model agreed
Report a problem with this finding
Wording Test nodes are described as having "a 28-core Intel(TM) Xeon(TM) E5-2680 v4 CPU running at 2.40GHz".
- p. 10 Section VI-A, test cluster hardware
Every node is configured with a 28- core IntelTM XeonTM E5-2680 v4 CPU running at 2.40GHz
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: that the Xeon E5-2680 v4 has 14 cores and 28 threads. The text is as quoted on p10. If that fact holds, 28 cores would mean two sockets, or 28 threads rather than cores. Only the authors can confirm the node configuration.
Second check: another model agreed
Report a problem with this finding
Wording Table I gives Batch ETL "Query Duration" as "20 min - 5 hr", but in the Fig. 7 runtime CDF the Batch ETL curve is at about 45–50% by 4 sec, about 83% by 1 min, and near 100% by about 17 min.
- p. 11 Table I, Batch ETL row, Query Duration
20 min - 5 hr
- p. 10 Fig. 7, Batch ETL curve
Query runtime distribution for selected use cases
Only the authors can say what is right here.
Judge's note: Read from the p10 Fig. 7 image and the p11 Table I. Table I may give typical durations rather than the observed distribution, and Fig. 7 counts every successful query that reads data. Neither caption says so, so the authors should clarify which quantity each one describes.
Second check: another model agreed
Report a problem with this finding
Wording Table I gives Interactive Analytics "Query Duration" as "10 sec - 30 min", but in Fig. 7 the Interactive Analytics CDF is already about 50% at 1 sec and about 75% at 4 sec.
- p. 11 Table I, Interactive Analytics row
10 sec - 30 min
- p. 10 Fig. 7, Interactive Analytics curve
Interactive Analytics
Only the authors can say what is right here.
Judge's note: Read from the p10 Fig. 7 image and the p11 Table I. Most of the plotted queries fall below the 10 s lower bound in Table I. As in C013, the table may describe typical ranges, but the paper does not say so.
Second check: another model agreed
Report a problem with this finding
Typo Table I, Batch ETL row, has "Upto 1000 nodes" (it should read 'Up to'). Separately, the Introduction claims "scaling to thousands of worker nodes", whereas Sec. II and the Conclusion say "up to ∼1000 nodes".
- p. 11 Table I, Batch ETL row, Cluster Size
Upto 1000 nodes
- p. 1 Introduction, first bullet of notable characteristics
scaling to thousands of worker nodes
- p. 2 Section II, first paragraph
with sizes up to ∼1000 nodes
- p. 12 Conclusion, second paragraph
scaling up to ∼1000 nodes
Judge's note: 'Upto' is visible on the p11 image. The p1 phrase 'thousands of worker nodes' was checked on the crop and is a minor wording inconsistency with the ∼1000-node figure given in Sec. II (p2) and the Conclusion; it may describe engine capability rather than deployment size.
Second check: none (judge only)
Report a problem with this finding
Typo An article is missing in "creating and optimizing distributed execution plan." (it should read 'a distributed execution plan').
- p. 3 Section III, first line of page
creating and optimizing distributed execution plan
- p. 3 III Architecture overview
creating and optimizing distributed execution plan.
Judge's note: Visible on the p3 image, first line of the left column.
Second check: none (judge only)
Report a problem with this finding
Typo The article is duplicated in "This is a an important feature of Presto".
- p. 6 Section IV-D3 Split Assignment
This is a an important feature of Presto
Judge's note: Visible on the page image crop from p6.
Second check: none (judge only)
Report a problem with this finding
Typo A word is missing in "Connectors such Hive and Raptor take advantage" (it should read 'such as').
- p. 9 Section V-C
Connectors such Hive and Raptor take advantage
Judge's note: Visible on the page image crop from p9.
Second check: none (judge only)
Report a problem with this finding
Typo The text says "Table 1 outlines the connectors and deployments", but the table is labelled "TABLE I".
- p. 10 Section VI-A
Table 1 outlines the connectors
- p. 11 Table I caption
TABLE I
- p. 10 Section VI-A, first paragraph
Table 1 outlines the connectors and deployments
Judge's note: Checked p10 and the p11 caption. The pointer reaches the correct table; only the numbering style differs.
Second check: none (judge only)
Report a problem with this finding
Typo Table I, Batch ETL row, Cluster Size column reads "Upto 1000 nodes"; it should read "Up to 1000 nodes".
- p. 11 Table I, Batch ETL, Cluster Size
Upto 1000 nodes
Judge's note: I checked the crop of Table I on p.11. The word is printed as one word, "Upto", so this is not an extraction artefact. It is a cosmetic misspelling.
Second check: none (judge only)
Report a problem with this finding
Typo Section VII, 'Adaptiveness over configurability': "large amounts of memory and CPU was utilized" has a plural subject with a singular verb; it should read "were utilized".
- p. 11 VII Adaptiveness over configurability
large amounts of memory and CPU was
Judge's note: I checked the crop of p.11, left column. The subject is the plural "large amounts of memory and CPU", which takes "were", but the page prints "was". This is a grammatical slip with no effect on meaning.
Second check: none (judge only)