|
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
|
т.е. в зарплате вообще, каждый год обрабатывается как бы отдельно от соседнего, даже при переходящих расчетах
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |