From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Lorenz <mlorenz1(at)hotmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Query slows after offset of 100K |
Date: | 2008-02-14 21:55:03 |
Message-ID: | 19472.1203026103@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Michael Lorenz <mlorenz1(at)hotmail(dot)com> writes:
> 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.
Well, my first question is whether that user interface is actually
useful to anyone. If you have a dictionary and you want to look up
"foosball", do you start by guessing that it's on page 432? No, you
look for the "F" tab. I'd suggest that what you want is to present
links that let people go to specific spots in the key distribution,
rather than expressing it in terms of so-many-pages.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Chris | 2008-02-14 23:48:08 | Re: Join Query Perfomance Issue |
Previous Message | Mark Lewis | 2008-02-14 20:32:12 | Re: Query slows after offset of 100K |