подсчет с группировкой и сохранение/кеширование результата

есть таблица с товарами/объявлениями.
основные параметры - покупка/продажа/обмен/бесплатно
таблицы с товарами от 1 до 10 миллионов записей, записи постоянно удаляются/добавляются, обновляется время у старых записей.
выборка с join по нескольким таблицам:

для формирования страницы выбираем строки у которых время свежее.
(дополнительно могут быть в разрезе разделов/категорий, по городам/регионам, новые/бу и тд.)

класс имеет конструктор, который изначально считает:

1) count с группировкой по покупка/продажа/обмен/бесплатно.
проблема - после 500к строк начинает тормозить, тяжелый
ВОПРОС 1
что предпринять чтоб постоянно не выполнять count ?

2) count с группировкой по подкатегориям текущего раздела (4ступени вложенности).
ВОПРОС 2 проблема и вопрос тотже?

3)
проблема - сложность построения пагинаторв для больших данных, те выборки данных на страницу далеко за первую - пока решена ограничением страниц в 500 и предложением пользователю уточнить параметры.
ВОПРОС 3 как улучшить?

прошу подсказать подходящее решение или направить, как пример - там всегда сумма по подкатегориям : olx (сумма частные/бизнес), avito

пока вижу так:
создать таблицу и складывать ключ/значение в нее
перед запросом проверять эту таблицу и время вставки, если прошло до 10 минут - отдавать пользователю сэти данные, иначе - новый тяжелый запрос

спасибо.

Да, отдельная таблица с аггрегированными данными.
Всегда отдавать данные из этой таблицы, обновлять фоновой задачей (кроном, как самое простое)

-----
PostgreSQL DBA

тк разнообразных запросов очень и очень много я больше склоняюсь к заполнению таблицы из класса, а потом можно порциями кроном обновлять. тока не пойму в таблицу ложить хэш запроса, сам запрос...

может подробней изложите свое видение?

Это не моё видение, это общий подход. count делать дорого. Аггрегацию ещё дороже. Раз данных довольно много - значит надо сделать меньше данных.
Может быть несколько агрегатов надо сделать.

-----
PostgreSQL DBA

попробовал - пришел к выводу, что в таблице хранить напряжно, тк выборка может иметь комбинацию до 10 фильтров, + все это * на 1000 городов * 1000 рубрик - очень много. да и если основная таблица обновляется постоянно, то дергать обновлениями громадную таблицу не хорошо.
пока реализовал так - закрутил мемкеш и скидываю результаты тяжелых запросов с count туда на некоторое время.
однако тут пришлось пожертвовать точностью данных - тк основная таблица постоянно обновляется - точность результата выборок задерживается на время хранения в кеше, но хотя бы снижается количество запросов к базе...

подскажите - чем может быть чревато использование такого варианта?
- что попробовать/использовать/почитат ь еще?