Re: ORDER BY, LIMIT and indexes

From: Nikolas Everett <nik9000(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: ORDER BY, LIMIT and indexes
Date: 2013-08-06 16:09:44
Message-ID: CAPmjWd0-eY9dgRkg5n4M8c8fN2-1iMfbt0pwfxrfDYicic3LTg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Aug 5, 2013 at 9:22 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:

> Ivan,
>
> > Or, more generally, is there some set of circumstances under which the
> > catastrophic scenario will happen?
>
> Yes:
>
> SELECT * FROM table ORDER BY id DESC LIMIT 10 OFFSET 100000
>
> This is the "high offset" problem, and affects all databases which
> support applications with paginated results, including non-relational
> ones like SOLR. The basic problem is that you can't figure out what is
> OFFSET 100000 without first sorting the first 100000 results.
>
> The easiest solution is to limit the number of pages your users can
> "flip through". Generally anyone asking for page 10,000 is a bot
> screen-scraping your site, anyway.

Another solution is to build pages from the maximum id you pulled in the
last page so page one is:
SELECT * FROM table ORDER BY id DESC LIMIT 10
and page 2 is:
SELECT * FROM table WHERE id > 19 ORDER BY id DESC LIMIT 10
and page 3 is:
SELECT * FROM table WHERE id > 37 ORDER BY id DESC LIMIT 10
and so on. You build your urls like this:
http://yousite.com/browse
http://yousite.com/browse?after=19
http://yousite.com/browse?after=37
and so on.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff Janes 2013-08-06 16:57:17 Re: ORDER BY, LIMIT and indexes
Previous Message Claudio Freire 2013-08-06 15:47:01 Re: ORDER BY, LIMIT and indexes