Есть таблица (пример просто суть):
фамилия
имя
отчество
др
квартира
дата С

Запросы к ней идут двух типов:
1. поиск по фио др с целью получить адреса, где проживал человек
2. поиск по квартире с целью получить всех кто в ней когда-либо проживал

На данный момент все хорошо: делается два индекса для каждого поиска и вперед

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

2. Можно создать два "хранилища" с разбивкой на части, каждое будет работать для конкретного типа запросов
и иметь соответствующую разбивку например одно разбито на части по хэшу фио, другое - по номеру квартиры
Плюсы:
- при поиске будем сразу обращаться к нужной части, а не лезть в каждую отдельно
Минусы:
- немного сложнее в реализации и сопровождении
- требуется больше места на дисках
- затратнее удалить "старые" данные
Есть опыт в использовании первого варианта. Все работает вполне сносно и по скоростям и по сопровождению. Но.
Вопрос: Какие есть еще варианты? Может реален какой-то симбиоз/компромисс?
При этом реально типов запросов может быть не два, а например 5, создавать под каждый отдельные таблицы/индексы только для
пранинга острой необходимости нет конечно.

ElicТ.е. это единственная причина партиционирования?
Единственная причина - немного удобнее администрировать мелкие таблички, чем одну большую,
"отрезать" данные скорее, никто и не собирается.

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