OFF: Новая навигация по списку веток

При разработке нового движка форума обнажилась следующая проблема. При "страничной парадигме", когда под списком тем выводятся номера страниц "1 2 3 4 ... 10 >>" возникают тормоза с выводом больших (глубоких) страниц. Например, если запросить страницу №40, то в запросе будет что-то типа LIMIT 800,20 и MySQL вынужден просматривать все предыдущие 800 веток, чтобы показать эту страницу с учётом фильтра из ваших личных настроек (отключенные разделы/секции). Скорость просмотра - примерно 500 веток в секунду. Для небольших номеров страниц работает быстро, для больших - всё медленнее и медленнее. Поэтому сейчас на мисте запрещены запросы с номером страницы > 50. Это слишком перегружает сервер. Кстати, такой же проблемой страдает и RSDN.ru. На Т1С проблема не стоит так остро, потому что список актульных веток умещается на 40-50 страницах, а архив умещается на 300 страницах.

Формулирую задачу. Требуется ускорить показ списка тем при любой глубине запроса. Значительного ускорения можно добиться, если в запросе добавить условие на дату, которое отсечёт ту часть базы, которую не надо просматривать. В этом случае индекс по полю updated будет задействован эффективно (не только для сортировки, но и для отбора), а LIMIT будет содержать маленькие значения, например, LIMIT 0,20.

Вижу единственный метод решения: отказаться от "страничной парадигмы" и привязаться ко времени (даты или периоды). Номер страницы в принципе не несёт никакой полезной информации, а вместо него выводить даты или период.

Я предлагаю сделать так:
Вместо номеров страниц показывать следующее:
<< интервал >>

где "интервал" показывает границы интервала: даты первой и последней ветки в выборке.

Конкретные примеры:

Главная страница:
<< 16:40 - 16:59

При щелчке на ссылке "<<" (влево по оси времени, т.е. в прошлое) показываем предыдущие 20 веток (или то число, которое указано в личных настройках) и видим:
<< 16:09 - 16:39 >>

Теперь доходим до страницы, где есть ветки из двух дат (допустим в полночь):
<< 29 янв 23:50 - 30 янв 05:60 >>

А теперь делаем отбор по секции, и там есть ветки за несколько дней (больше 2), но в рамках одного месяца. В этом случае время уже несущественно и его не показываем:
<< 1 - 5 янв >>

Если секция обновляется нечасто и на одной странице есть ветки за 2 месяца, то видим название месяца у обоих границ интервала:
<< 30 янв - 3 фев >>

Если же год не является текущим или в выборке попались ветки за 2 месяца, но из разных лет (например, в Новый год), то в интервале ещё указывается и год:
<< 31 дек 2006 - 1 янв 2007 >>

А теперь делаем отбор по очень редко обновляемой секции, где на одной странице есть ветки за несколько месяцев (больше 2), в этом случае дни уже несущественны и показываем только месяцы:
<< окт - дек >>

или с учетом года, если находимся на границе лет:
<< ноя 2006 - янв 2007 >>

или в рамках одного года, но год меньше текущего:
<< окт 2006 - дек 2006 >>

и т.д.

Преимущества такой навигации следующие:
1. Простота и интуитивная понятность интерфейса, минимум ссылок (шаг в прошлое и шаг в будущее) и минимум личных настроек (кол-во веток на страницу).
2. Всегда понятно, где ты находишься на оси времени. Причём, чем больше плотность веток, тем детальнее показывается интервал (от минут, до месяцев и лет).
3. Можно пошагово углубиться в прошлое или вернуться в будущее. При этом размер шага в количестве веток всегда одинаковый, но расстояние во времени, которое мы "проходим" за этот шаг - разное, в зависимости от реальной плотности веток (интенсивности обновления).
4. Размер страницы (количество веток на странице) не меняется и в точности равен тому, что указан в личных настройках или 20 веток на страницу по умолчанию.
5. Страницы показываются быстро вне зависимости от глубины запроса во времени, плотности веток и личных настроек. Это достигается за счёт того, что в гиперссылки "<<" и ">>" добавляется метка времени, с которой начинается выборка из базы данных.

Недостатки:
1. Нельзя переместиться сразу на несколько шагов во времени.
2. Невозможно предсказать, какой период будет показан при следующем шаге
3. У некоторых специалистов по юзабилити (Camino) есть сомнения в том, что информация о текущем периоде является полезной. Но здесь лично я не согласен, поскольку основа любой навигации - это ответ на вопрос "Где я сейчас?"

Что скажете?