OFFSET clause in a
SELECT 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
0 produces the same result as leaving out the
OFFSET clause. Always use this clause
in combination with
ORDER BY (so that it is clear which item should be first, second, and so
LIMIT (so that the result set covers a bounded range, such as items 0-9, 100-199,
and so on).
In Impala 1.2.1 and higher, you can combine a
LIMIT clause with an
OFFSET clause to produce a small result set that is different from a
top-N query, for example, to return items 11 through 20. This technique can be used to
simulate "paged" results. Because Impala queries typically involve substantial
amounts of I/O, use this technique only for compatibility in cases where you cannot
rewrite the application logic. For best performance and scalability, wherever practical,
query as many items as you expect to need, cache them on the application side, and
display small groups of results to users using application logic.
The following example shows how you could run a "paging" 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.
[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 | +----+