Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support OFFSET in SELECT #2661

Closed
jcowanpdx opened this issue Apr 8, 2015 · 6 comments
Closed

Support OFFSET in SELECT #2661

jcowanpdx opened this issue Apr 8, 2015 · 6 comments

Comments

@jcowanpdx
Copy link

LIMIT is supported. Is it possible to add OFFSET as well? I understand I can do that manually but having native support would be nice. The downside of manual paging is more data transmitted over the wire from server to client.

@electrum
Copy link
Contributor

electrum commented Apr 8, 2015

We can add this, but performing pagination using this method is extremely inefficient, especially for an analytic database like Presto that often has to perform a full table or partition scan. Additionally, the results will not necessarily be consistent between queries, so you can have duplicate or missing results when navigating between pages. It is better for the application to cache the result set and perform pagination itself using the cached data.

Here is a good article on the subject: http://use-the-index-luke.com/no-offset

@jcowanpdx
Copy link
Author

Thanks. Definitely agree it's a better solution and have dealt with similar solutions on other platforms. We're working behind a legacy interface that allows arbitrary pagination, so that gives us some challenges using the stated approach. We've got some workarounds planned for now until we can rework the interface. Cheers.

@hongyu01
Copy link

Hi @jcowanpdx
would you please share your workaround approach,
thanks very much:)
we're facing such problem like you;

@martint
Copy link
Contributor

martint commented Apr 26, 2016

For the record, the standard syntax is:

<query expression> ::= 
      [ <with clause> ] 
      <query expression body>
      [ <order by clause> ] 
      [ <result offset clause> ] 
      [ <fetch first clause> ]

<result offset clause> ::= OFFSET <offset row count> { ROW | ROWS }

<offset row count> ::= <simple value specification>

A <query expression> may contain both a <result offset clause> and a <fetch first clause>, in which case the <result offset clause> is applied first, followed by the <fetch first clause>.

i) If <result offset clause> is not specified, then let RORC be 0 (zero).

b) If RORC is less than 0 (zero), then an exception condition is raised: data exception — invalid row count in result offset clause.

@rdsedmundo
Copy link

I really I'd like to hear what's the best recommendation around that.

I'm using AWS Athena which I suppose is backed by PrestoDB under the hood, and I'm needing a mechanism to do this sort of pagination, the tricky thing is that my CSV format by itself doesn't include a sequential field like an id or a created_at that I could filter for it manually using WHERE and then applying the LIMIT clause accordingly.

Including the id is possible on the CSV, but I really didn't want to do that mandatorily.

@stale
Copy link

stale bot commented Nov 7, 2020

This issue has been automatically marked as stale because it has not had any activity in the last 2 years. If you feel that this issue is important, just comment and the stale tag will be removed; otherwise it will be closed in 7 days. This is an attempt to ensure that our open issues remain valuable and relevant so that we can keep track of what needs to be done and prioritize the right things.

@stale stale bot added the stale label Nov 7, 2020
@stale stale bot closed this as completed Nov 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants