|
|
|
партицирование. ругается на тригер update before
|
|||
|---|---|---|---|
|
#18+
ситуация такая: таблица а разбита на кучу партиций работает так: при инсерте определяем в какую пачку записать при апдейте удаляем OLD инсертим NEW (тут срабатывает тригер инсерт, вдруг по новым условиям запись должна физически перенестись в другую пачку) такой запрос ругается из шедуллера: Код: sql 1. 2. 3. 4. -- все лишнее из запроса поудалял оставил, то что создает ошибку: ERROR: tuple to be updated was already modified by an operation triggered by the current command Подсказка: Consider using an AFTER trigger instead of a BEFORE trigger to propagate changes to other rows. вопрос: можно ли тригерр на UPDATE переместить в AFTER ? или может есть способ как в запросе избежать такой ошибки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2016, 11:45 |
|
||
|
партицирование. ругается на тригер update before
|
|||
|---|---|---|---|
|
#18+
Legushka, всегда используйте тригеры AFTER, кроме тех случаев когда необходим имменно BEFORE. если в данном случае не расчитываются данные для NOT NULL полей и т.п. переделывайте на AFTER. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2016, 11:55 |
|
||
|
партицирование. ругается на тригер update before
|
|||
|---|---|---|---|
|
#18+
Lonepsycho, рекомендация спорная. особо -- в свете того, что в before логике события худо--бедно упорядочены, а в after -- "просто пипетс какойта" (где--то тут в форуме есть темка на предмет измерения очередности событий в after, и цитируется жевание соплей небезызвестным супергурьем томом лейном на эту тему) 111 но ясный--красный: -- если вы хотите пользоваться returning -- вам ничего не остается как пользоваться after логикой в триггерах партицирования. как во вставке, так и в обновлении. PS я до сих пор не понял, чревато ли это лишними дисковыми, т.е. какие накладные на цепочку--"инсерт в предка--делете фром онли предок--инсерт в дитё". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2016, 12:17 |
|
||
|
партицирование. ругается на тригер update before
|
|||
|---|---|---|---|
|
#18+
qwwq подскажите а если в запросе просто убрать все returning то логика тригерров с before сработает? для чего делалось все в одном with: просто изначально для всех апдейтов используются практически одни и теже таблицы, многие из них тяжелые я предположил что если все загнать в один with запрос то к исходным таблицам можно обратиться один раз и загнать их в память returning * делался на каждом шаге только для проверки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2016, 12:34 |
|
||
|
партицирование. ругается на тригер update before
|
|||
|---|---|---|---|
|
#18+
Legushka, Я думаю, что вы попадаете в случай, когда запись не двигается и два подзапроса пытаются менять одну и ту же запись, о чём и говорит ошибка. Для перещения записей AFTER точно не подойдёт -- всё уже случилось и перенаправить в другую таблицу вы не сможете. Я бы рекомендовал отойти от столь сложных запросов. Либо встраивайте такую логику в PL/pgSQL функции IF-блоками. Либо совсем откажитесь от миграции записей, т.е. EXCEPTION в случае NEW.key_col IS DISTINCT FROM OLD.key_col. У меня в практике не было пока случаев, когда требовалась бы миграция записей. У нас это либо встроено в логику приложения (удаляем батч целиком, потом полностью его пересчитываем), либо база версионная и изменение == замена статуса у старой записи + вставка новой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2016, 13:18 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39246059&tid=1997206]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
226ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
| others: | 252ms |
| total: | 595ms |

| 0 / 0 |
