Re:

у нас агрегатор служб такси. как я сказал выше - сейчас в среднем
15 тыс машин. от сервиса координат требуется отвечать на вопросы

1. трек водителя
2. ближайшие машины к точке
3. иногда (ручные запросы) - разбор полетов

первый вопрос отвечает быстро - из индекса по 15К (25К в пике)
последних точек.

я так понимаю тут ошибка закралась ... не первый запрос, а второй ?
так как по последним точкам собрать трек водилы не реально :-)

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

Что есть :
- у  Вас  примерно/максимум 4ГБ данных (с индексами) в день.
- вы запускаете один единственный запрос, а именно поиск по внешнему индексированному ключу к данным которые лежат в кеше.
(про возможные джойны с остальными табличками я не рассматриваю так как не интересно)
- вы успеваете проанализировать/проагрегировать приходящие данные и по уже проагрегированным данным делаете запрос номер два (кто тут рядом сейчас).
- ручные запросы ...
- данные что ушли из кеша уже лежат только как архив.


Подведу итоги:
- из всей базы реально доступно менее одного процента данных так как кеша мало (2 дня из: "хотя бы одного года")
- по этим данным вы делаете запрос одного вида.
- и параллельно костыль в виде агрегатора входящие данные и уже по ним ищете второй вопрос "кто рядом сейчас"
- по данным "мёртво" лежащим на диске можно делать ручные запросы ... но долго ждать пока диски всё перечитают )))
- один  пользователь базы данных ...

на отдельной машине поддерживаете копию...

Вы знаете Дмитрий для Вашей задачи действительно "биг дата" не нужна, а Вы уверены что для этой задачи нужен  постгрес ?
Или вы его взяли так как уже был в прожекте ?
Если из всей базы данных данные используете только за последние пару дней .. почему вы их храните в базе ? 

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

Поймите же Дмитрий что обработка данных в виде "спагетти" (я так называю данные в виде лог файлов) не является целевой
задачей для реляционной базы данных которой является постгрес. Конечно можно и микроскопом забивать гвозди, это даже
не запрещено, и открою Вам секрет этим таки многие занимаются, но есть для такого рода данных совсем другие "инструменты".


Хорошего Вам для/вечера/ночи.

Константин.