Имя: Пароль:
1C
1С v8
postgree. Партиционирование. Использует кто?
0 kev789
 
05.06.13
08:34
Тут http://postgresql.leopard.in.ua/html/#x1-90002.2 указано что сабж может дать улучшение производительности в ряде случаев.

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

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

Кто нибудь использует? поделитесь впечатлениями.
1 Фрэнки
 
05.06.13
08:46
Ссылка на партиционирование не корректная:
http://postgresql.leopard.in.ua/html/#x1-470003
вот эта должна быть
2 Фрэнки
 
05.06.13
08:47
документация полезная, спасибо!
в закладки сохраню - буду на досуге изучать
3 Фрэнки
 
05.06.13
08:55
(0) А как думаешь, тексты запросов, которые уже написаны в конфигурации, их нужно изменять или они автоматически внутри  QUERY PLAN будут полчаться? Просто в тексте явно не увидел, каким образом будет использоваться эта фишка с партициями при написании запросов.
4 kev789
 
05.06.13
09:00
(3) вроде тема как раз что ничего не надо изменять.

Параметр «constraint_exclusion» отвечает за оптимизацию запросов, что повышает производительность для партиционированых таблиц.
5 sikuda
 
05.06.13
09:03
Зная как 1С привязала Postgresql и лицензионную политику (http://v8.1c.ru/predpriyatie/questions_licence.htm#65) - саперы вперед!
Потестировать это я за всегда, но в продакшин...
6 kev789
 
05.06.13
09:06
(3)  Начиная с 8.4 версии PostgreSQL «constraint_exclusion» может быть «on», «off» и «partition». По умолчанию (и рекомендуется) ставить «constraint_exclusion» не «on», и не «off», а «partition», который будет проверять «CHECK» только на партиционированых таблицах.

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

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

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

И еще попробовал такую схему. При создании таблицы потомка не создаются автоматически индексы которые описаны в таблице-предке. Или может я где тупанул?
7 Фрэнки
 
05.06.13
09:47
(6) думаю, что прирост производительности должен быть. Просто сам много раз, при разборке  текста запроса обращал внимание, что в нем должна сразу вытаскиваться из БД в память вся таблица, а уже потом поставится условие, например, по регистратору. Тогда получается, что как раз вариант с отнесением в партицию данных за неактуальные года даст хороший прирост к скорости выполнения запроса.
8 Фрэнки
 
05.06.13
09:51
А ведь как бы это было удобно на регистрах расчета - в зарплате прошлые года практически вызываются редко, но удалять их нельзя.
9 Фрэнки
 
05.06.13
09:53
т.е. в зарплате вообще, каждый год обрабатывается как бы отдельно от соседнего, даже при переходящих расчетах
Независимо от того, куда вы едете — это в гору и против ветра!