Re: Query slows after offset of 100K

Поиск
Список
Период
Сортировка
От Michael Lorenz
Тема Re: Query slows after offset of 100K
Дата
Msg-id BAY111-W375B12EB37C7EF3BE82BE793250@phx.gbl
обсуждение исходный текст
Ответ на Re: Query slows after offset of 100K  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Query slows after offset of 100K  (Mark Lewis <mark.lewis@mir3.com>)
Re: Query slows after offset of 100K  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Query slows after offset of 100K
Следующее
От: Mark Lewis
Дата:
Сообщение: Re: Query slows after offset of 100K