Тут http://postgresql.leopard.in.ua/html/#x1-90002.2 указано что сабж может дать улучшение производительности в ряде случаев.

Даст ли что-то в плане производительности если разбить например таблицу регистра партии товаров на складах по годам.

Мне кажется  что если положить разбитые таблицы на один винт то смысла нет. Я прав?

Кто нибудь использует? поделитесь впечатлениями.

Ссылка на партиционирование не корректная:
http://postgresql.leopard.in.ua/html/#x1-470003
вот эта должна быть

документация полезная, спасибо!
в закладки сохраню - буду на досуге изучать

(0) А как думаешь, тексты запросов, которые уже написаны в конфигурации, их нужно изменять или они автоматически внутри  QUERY PLAN будут полчаться? Просто в тексте явно не увидел, каким образом будет использоваться эта фишка с партициями при написании запросов.

(3) вроде тема как раз что ничего не надо изменять.

Параметр «constraint_exclusion» отвечает за оптимизацию запросов, что повышает производительность для партиционированых таблиц.

Зная как 1С привязала Postgresql и лицензионную политику (http://v8.1c.ru/predpriyatie/questions_licence.htm#65) - саперы вперед!
Потестировать это я за всегда, но в продакшин...

(3)  Начиная с 8.4 версии PostgreSQL «constraint_exclusion» может быть «on», «off» и «partition». По умолчанию (и рекомендуется) ставить «constraint_exclusion» не «on», и не «off», а «partition», который будет проверять «CHECK» только на партиционированых таблицах.

У меня в conf:
#constraint_exclusion = partition    # on, off, or partition

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

Даст ли это прирост производительности? вот в чем вопрос.

И еще попробовал такую схему. При создании таблицы потомка не создаются автоматически индексы которые описаны в таблице-предке. Или может я где тупанул?

(6) думаю, что прирост производительности должен быть. Просто сам много раз, при разборке  текста запроса обращал внимание, что в нем должна сразу вытаскиваться из БД в память вся таблица, а уже потом поставится условие, например, по регистратору. Тогда получается, что как раз вариант с отнесением в партицию данных за неактуальные года даст хороший прирост к скорости выполнения запроса.

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

т.е. в зарплате вообще, каждый год обрабатывается как бы отдельно от соседнего, даже при переходящих расчетах