Re: Query slows after offset of 100K

From: Michael Lorenz <mlorenz1(at)hotmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Query slows after offset of 100K
Date: 2008-02-14 19:49:22
Message-ID: BAY111-W375B12EB37C7EF3BE82BE793250@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


Fair enough, and I did think of this as well. However, I didn't think this was a viable option in my case, since we're currently allowing the user to randomly access the pages (so $lastkey wouldn't really have any meaning). The user can choose to sort on object ID, name or modification time, and then go straight to any page in the list. With 750K records, that's around 37K pages.

Maybe a better way to phrase my question is: how can I paginate my data on 3 different keys which allow random access to any given page, and still get reasonable performance? Should I just force the user to limit their result set to some given number of records before allowing any paginated access? Or is it just not practical, period?

Thanks,
Michael Lorenz

----------------------------------------
> To: mlorenz1(at)hotmail(dot)com
> CC: pgsql-performance(at)postgresql(dot)org
> Subject: Re: [PERFORM] Query slows after offset of 100K
> Date: Thu, 14 Feb 2008 14:08:15 -0500
> From: tgl(at)sss(dot)pgh(dot)pa(dot)us
>
> Michael Lorenz writes:
>> My query is as follows:
>> SELECT o.objectid, o.objectname, o.isactive, o.modificationtime
>> FROM object o
>> WHERE ( o.deleted = false OR o.deleted IS NULL )
>> AND o.accountid = 111
>> ORDER BY 2
>> LIMIT 20 OFFSET 10000;
>
> This is guaranteed to lose --- huge OFFSET values are never a good idea
> (hint: the database still has to fetch those rows it's skipping over).
>
> A saner way to do pagination is to remember the last key you displayed
> and do something like "WHERE key> $lastkey ORDER BY key LIMIT 20",
> which will allow the database to go directly to the desired rows,
> as long as you have an index on the key. You do need a unique ordering
> key for this to work, though.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

_________________________________________________________________
Your Future Starts Here. Dream it? Then be it! Find it at www.seek.com.au
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Ahet%3Ask%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_Future&_m=EXT

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Lewis 2008-02-14 20:32:12 Re: Query slows after offset of 100K
Previous Message Tom Lane 2008-02-14 19:08:15 Re: Query slows after offset of 100K