Вообще всё зависит от сценариев использования - как типовых при работе приложения, так и административных (размещение на носителях, зачистка устаревших данных и т.д. и т.п.).
Для разных сочетаний сценариев показаны различные стратегии секционирования.
Потому, прежде чем "резать к чёртой матери не дожидаясь перитонита" (с) - определитесь вместе с dba какие конкретно преимущества собираетесь получить и не сломаете ли какой-нибудь относительно редко используемый функционал (пример: иногда забывают про годовую отчётность).
Само по себе уменьшение размера отдельного сегмента путем дробления одного большого на 512 помельче принципиальной разницы с точки зрения отбора данных по ключу не даст, если только не используется FTS.
А если есть запросы "по pk" вида between ... and ... - то для таких положение ухудшится.
Кроме того, для неудачных с т.з. размещения данных запросов (не по pk=:x) субд будет склонна генерировать планы с параллельным исполнением - убедитесь, что имеете достаточный запас CPU и умеете с такими планами работать.