mirror of
https://github.com/apache/impala.git
synced 2026-01-26 21:02:23 -05:00
3be0f122a5
These are refugees from doc_prototype. They can be rendered with the DITA Open Toolkit version 2.3.3 by: /tmp/dita-ot-2.3.3/bin/dita \ -i impala.ditamap \ -f html5 \ -o $(mktemp -d) \ -filter impala_html.ditaval Change-Id: I8861e99adc446f659a04463ca78c79200669484f Reviewed-on: http://gerrit.cloudera.org:8080/5014 Reviewed-by: John Russell <jrussell@cloudera.com> Tested-by: John Russell <jrussell@cloudera.com>
67 lines
2.3 KiB
XML
67 lines
2.3 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
|
|
<concept rev="1.2.1" id="offset">
|
|
|
|
<title>OFFSET Clause</title>
|
|
<prolog>
|
|
<metadata>
|
|
<data name="Category" value="Impala"/>
|
|
<data name="Category" value="SQL"/>
|
|
<data name="Category" value="Querying"/>
|
|
<data name="Category" value="Reports"/>
|
|
<data name="Category" value="Developers"/>
|
|
<data name="Category" value="Data Analysts"/>
|
|
</metadata>
|
|
</prolog>
|
|
|
|
<conbody>
|
|
|
|
<p>
|
|
The <codeph>OFFSET</codeph> clause in a <codeph>SELECT</codeph> query causes the result set to start some
|
|
number of rows after the logical first item. The result set is numbered starting from zero, so <codeph>OFFSET
|
|
0</codeph> produces the same result as leaving out the <codeph>OFFSET</codeph> clause. Always use this clause
|
|
in combination with <codeph>ORDER BY</codeph> (so that it is clear which item should be first, second, and so
|
|
on) and <codeph>LIMIT</codeph> (so that the result set covers a bounded range, such as items 0-9, 100-199,
|
|
and so on).
|
|
</p>
|
|
|
|
<p conref="../shared/impala_common.xml#common/limit_and_offset"/>
|
|
|
|
<p conref="../shared/impala_common.xml#common/example_blurb"/>
|
|
|
|
<p>
|
|
The following example shows how you could run a <q>paging</q> query originally written for a traditional
|
|
database application. Because typical Impala queries process megabytes or gigabytes of data and read large
|
|
data files from disk each time, it is inefficient to run a separate query to retrieve each small group of
|
|
items. Use this technique only for compatibility while porting older applications, then rewrite the
|
|
application code to use a single query with a large result set, and display pages of results from the cached
|
|
result set.
|
|
</p>
|
|
|
|
<codeblock>[localhost:21000] > create table numbers (x int);
|
|
[localhost:21000] > insert into numbers select x from very_long_sequence;
|
|
Inserted 1000000 rows in 1.34s
|
|
[localhost:21000] > select x from numbers order by x limit 5 offset 0;
|
|
+----+
|
|
| x |
|
|
+----+
|
|
| 1 |
|
|
| 2 |
|
|
| 3 |
|
|
| 4 |
|
|
| 5 |
|
|
+----+
|
|
[localhost:21000] > select x from numbers order by x limit 5 offset 5;
|
|
+----+
|
|
| x |
|
|
+----+
|
|
| 6 |
|
|
| 7 |
|
|
| 8 |
|
|
| 9 |
|
|
| 10 |
|
|
+----+
|
|
</codeblock>
|
|
</conbody>
|
|
</concept>
|