Re: Query slows after offset of 100K - Mailing list pgsql-performance

From Michael Lorenz
Subject Re: Query slows after offset of 100K
Date
Msg-id BAY111-W375B12EB37C7EF3BE82BE793250@phx.gbl
Whole thread Raw
In response to Re: Query slows after offset of 100K  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Query slows after offset of 100K
Re: Query slows after offset of 100K
List 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
currentlyallowing the user to randomly access the pages (so $lastkey wouldn't really have any meaning).  The user can
chooseto 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
toany given page, and still get reasonable performance?  Should I just force the user to limit their result set to some
givennumber of records before allowing any paginated access?  Or is it just not practical, period? 

Thanks,
    Michael Lorenz

----------------------------------------
> To: mlorenz1@hotmail.com
> CC: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Query slows after offset of 100K
> Date: Thu, 14 Feb 2008 14:08:15 -0500
> From: tgl@sss.pgh.pa.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@postgresql.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

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Query slows after offset of 100K
Next
From: Mark Lewis
Date:
Subject: Re: Query slows after offset of 100K