Comments
7
Спасибо за статью, сохранил *thumbs up*
Рад, что понравилось.
Спасибо за статьи, довольно доступная подача не самого простого материала. Хорошо помогает упорядочить свои отрывочные знания.
Уточните, пожалуйста, следующий момент. Вот цитата: "Команда UPDATE сама выбирает минимальный подходящий режим блокировки; обычно строки блокируются в режиме FOR NO KEY UPDATE".
Плюс к этому известно, что любой апдейт в постгресе все равно действует как delete+insert, даже если обновляется одно "простое" поле. Во многих ORM удобно использовать save метод, который генерирует update на все поля, и изменившиеся, и нет. Постгрес достаточно умный, чтобы понять, что KEY поля не менялись, или нет? И вообще практика при апдейте указывать только нужные поля реально несёт какую-то пользу (ну кроме сокращения трафика).
Постгрес достатчно умный, чтобы понять, что KEY поля не менялись, или нет?
Достаточно (:
И вообще практика при апдейте указывать только нужные поля реально несёт какую-то пользу
Безусловно несет.
Если вы обновляете поля, которых нет ни в одном индексе, у вас работает HOT. Но если вы обновляете все поля (и у вас на таблице есть хотя бы один индекс) — увы.
Ну и журнальные записи будет меньше.
А HOT будет применен, если обновится поле с индексом, но значение останется тем же? По ссылке про него прочитал, но не совсем понятно, "обновление поля" — это любой апдейт или именно изменение значения.
Хм, век живи…
Я был уверен, что нет, но решил проверить. И оказалось, что если при обновлении значение фактически не меняется, то HOT работает. Более того, и в журнал ничего лишнего не пишется.
Так что обманул я вас, нет (почти) никакой разницы.
Спасибо. Явно указывать, что сохранять, все равно, конечно, надо, но в legacy коде хотя бы можно не рыться в надежде что-то таким образом оптимизировать :)
Only those users with full accounts are able to leave comments. Log in, please.
Блокировки в PostgreSQL: 2. Блокировки строк