Доброго здоровья, уважаемые!

Есть у меня в PostgreSQL базе таблица с миллионами строк. Для ускорения решил применить ее сегментирование(партицирование). Разделял по полю "date" по месяцам. Сделал следующее:

таблица с триггером


функция на триггере


Собственно, вопроса два. 

1) для самоуспокоения и просвещения. Во всех примерах в гугле динамические таблицы создаются после проверки их на существование. Я сделал через обработку исключения. На мой взгляд выгода в моем варианте в том, что при уже существующей таблице строка в нее записывается сразу, без проверки ее существования. Однако, возможно тут есть какие-то подводные камни, о которых я не знаю(например, затраты на возбуждение и обработку исключения болььше, чем проверка таблицы на существование). Просьба на них указать. 
2) практический вопрос. Никак не получается сделать уникальным поле "uid" в рамках таблицы "packages". Получается только на каждой партиции. Возможно ли это, и если да, то как?

И как оно ваще - работает?
Интересуюсь потому что знаком с ПГ лишь понаслышке.

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

Ну и вобще DDL в прикладной логике это моветон.

PS Почитал, оказывается в PG действительно с секционированием тоска-тоска 


Походу - нет. Ответ на столько же очевиден, насколько легко гуглится


А что ускоряете то?
Быть может оно вам и в пень не вдулось. Секционирование добавляет перфомансу в весьма специфических случаях.  В общем случае, оно скорее его уменьшает.

Это сообщение отредактировал(а) Zloxa - 18.9.2013, 00:18

Работает, подтаблицы создаются, данные читаются 


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


насколько я понимаю, секционирование ускоряет чтение на больших таблицах. В данном случае, если мне нужны сведения только за пару месяцев, то база и 
будет их искать только в 2 маленьких подтаблицах, а не лопатить все миллионы записей. В некоторых случаях даже получается перебор подтаблицы быстрее, чем поиск по индексу.
Конечно, есть какой-то оверхед на проверку условий при записи(это в моем случае терпимо) и при чтении(в этом случае ускорение от партицирования должно превышать оверхед).  Это в теории. На практике сейчас и хочу это проверить

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

Это сообщение отредактировал(а) Paher - 18.9.2013, 09:24

что с транзакцией? Транзакцию триггер при создании новой таблицы рвет?
Если это действительно так, это минус в карму постгру.

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


Повторяю.



не всякое чтение.

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

Это сообщение отредактировал(а) Zloxa - 18.9.2013, 09:57

Если я правильно понял вопрос, то не рвет, транзакции работают правильно, с полным откатом по ROLLBACK


Впрок по датам вряд ли получится предсказать, когда проект умрет и сколько надо сделать секций. А проект должен работать и без постоянной поддержки. Так что пришлось создавать динамически. Если коробит DDL в триггере, подскажите, как от него избавится

 

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


Это все понятно, естественно, это обдумал до секционирования, мои запросы позволяют снизить оверхед при разделении. Опять таки в теории. Сейчас провожу эксперименты, какой вариант  в действительности будет быстрее на одинаковых данных


Это сообщение отредактировал(а) Paher - 18.9.2013, 11:05

Я правильно понимаю что это означеат, что PG создает новую таблицу либо в контексте текущей транзакции, либо в автономной? Если так, пожалуй стоит забрать ранее выставленный минус в карму 


По этой причине определяют регламент проведения технических работ в рамках которого донарезаются секции.


Потому что индекс может обеспечивать уникальность лишь в пределах таблицы же.

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

На мой взгляд все же предпочтительнее автоматизация вспомогательных рутинных процессов, хоть и некрасивыми средствами. Машина не ошибается, а человек - сплошь и рядом. Могут забыть, могут неправильно написать. И не всегда возможно объяснить, например, заказчику не технарю, почему он должен постоянно следить за базой и даже что-то там делать




Секционирование реализовано частично, например, чтение  из секционированной таблицы не требует плясок с бубнами. А вот с записью - да, приходится костылей написывать 



за это огромное спасибо, что-то я это проворонил

Это сообщение отредактировал(а) Paher - 18.9.2013, 12:37

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


Секционирование не реализовано. Реализовано наследование, ограниченное исполнение, триггеры, правила, средствами которых можно добиться функционала близкого к функционалу секционирования 

Это сообщение отредактировал(а) Zloxa - 18.9.2013, 17:24