Ну у меня был.

Твои опасения понятны и даже если вендор гарантирует какие-то лимиты, в реальности система может становится нерабочей при приближении к ним. К примеру, Оракл хоть и допускает до тыщи колонок, но по факту даже если у тебя будет их 500, то это будет полный треш. Во-вторых абсолютно нормальны сомнения когда приходит идея что-то делать против общепринятых практик.

В моем случае решение было еще более «извращаенным» - была таблица фактов секционированная interval под дням и 1024 hash subpartitions. При этом было еще и измерение, которое изначально было секционировано только по дням, но потом его тоже прекроили interval * 1024 hash. Единственная причина для этого - измерение было ведущим при заходе в таблицу фактов и таким образом задействовался partition wise join. В partition wise join не было бы необходимости, если б в Oracle bloom filter был идеально реализован и при соединениях при заходе в факт нужные подсекции отсекались бы благодаря bloom filter, но на практике возникал ряд проблем, а при DML bloom filter на 11-й версии вообще не задействовался из-за бага.

Так что была таблица фактов в которой около 300 дней по 1к секций, то есть примерно 300к секций и столько же в измерении. Более того, в измерении одна секция это одна строка. В факте на каждый день боле 100М строк, соответственно данных на два порядка больше чем у тебя.

Один парень который был против таких выкрутасов говорил, что измерение фактически используется как альтернатива индекса при доступе в факт. Я вполне могу согласиться с такой формулировкой. И хорошо, когда есть кто-то кто может конструктивно покритиковать или попыться проверить на прочность когда ты предлагаешь что-то нестандертное. Еще очень важно, чтоб был кто-то твоего уровня или выше, кто может критически подойти к твоему решению а сдругой стороны поддержать его, если убедится в целесообразности. Важно когда это кто-то работающий с тобой и несущий ответственность. А что толку если кто-то в инетрнетах тебе даст зеленый свет? Тебе ж вред ли поможет аргумент на работе, что тебя кто-то на форуме поддержал.

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

Теперь больше к технической части. Понятное дело плюс subpartitions перед индексом – скорость вставки. Только мало кто задумывается насколько наличие индекса влияет на эту самую вставку. Если без индекса порция данных грузится меньше 20 мин, а с индексом более часа, то это уже вызывает определеннное желание лишний раз подумать как от него отказаться. Во-вторых различные DDL на таблице могут требовать перестройки индекса или его части – как тривиальный пример – сжатие секции. Это дополнительное время на maintenance, иногда весьма значительное.

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

Что следует учесть.
1. Становится весьма важной кляуза storage (initial … next …) . Например, если секция занимает мегабайт, а в ней небольшое число строк, то это весьма затратно. Умножь занимаемый размер на 90к.
2. Оптимизатору крышу не сносит, но стоит придерживаться разумного минимализма. То есть, не собирать гистограммы пока в них нет необходимости. Также в нашем случае НЕ собирали статистику по subpartitions – параметр granularity.
По факту сбор статистики вообще не выполнялся. Она собиралась единоразово. При открытии нового дня статистика копировалась с предыдущего. Ведь данных по дню еще нет, а статистика уже нужна.
3. Важно учесть housekeeping. То есть, архивирование старых данных, компрессию и вообще сопровождение подобных таблиц. Мы напоролись на лимит 1М секций, для того, чтоб этого избегать надо «сдвигать» нижнюю границу интервального секционирования. Лимит возникает не из-за фактического числа партиций а из-за разницы максимальной и минимальной фактической границы для интервального диапазона.
4. Ну и последняя рекомендация в стиле капитана очевидность. Во первых все пробуй и тщательно тестируй, во вторых минимизируй число секций. Может скорость вытягивания нужных данных особо не изменится если ты ументьшиьш число секций в 10 раз.

То есть по сути всё просто. Регламент сбора статистики, регламент архивирования, минимизация занимаемого места, минимизация числа секций, тщательное тестирование и взвешивание за и простив. :)

Прочитал три раза - так и не понял мысли.
Я вел речь про то, что если таблица состоит не из одного сегмента а из дестков тысяч, то озвученные параметры могут играть очень существенную роль.
С этим несогласие?