[kmike]

The first part of your post, until the offset talk, is exactly what I was talking about in the post #4. You'll need an appropriate compound index ending in "dateline" to take advantage of that however, and scanning it in reverse order (DESC) is why it was called a "reverse index".

Now to the offsets idea, you're just shifting the problem to another place if you want to keep the traditional thread pagination. Now instead of finding a first post on the requested page *once* you need to find the first posts for every page surrounding current page in the navigation area.
For example, looking at the first page in a thread, we'll have these pages in the pagination nav area:
1 2 3 4 11 51 101 Last
and you'll need the dateline offsets for the first posts on the pages 2, 3, 4, 11, 51, 101, and the last page. Ok, getting them for the first 10 pages is easy (though less effective) - just fetch 150 posts instead of 15, but what about pages 51, 101?

Now let's load page 10, what do we have in the pagination nav area?
First Prev 7 8 9 10 11 12 13 20 60 110 Next Last
You'll need an additional query to fetch the navigational data for the preceeding pages 7,8,9, and you still have to handle the pages 60, 110 somehow.

And another thing, basing the navigation on the pure dateline offsets is wrong - for busy enough forums/threads, some posts in a thread may have the same datelines. You can ignore it of course, but to be consistent you have to sort on dateline DESC, postid DESC or dateline ASC, postid ASC everywhere, otherwise the two posts with the same dateline will switch positions when they gradually move in the first half of the thread.