Так господа. А теперь по делу.

При обновлении код срабатывания HOT проверяет изменилось ли поле или нет НЕ ПО НАЛИЧИЮ его в update запросе а по совпадению внутреннего двоичного представления (поэтому простановка значения которая значение моля не меняет не влияет ни на HOT ни на TOAST механику причем TOAST если он не изменился даже при cold update останется в одной копии).
Поэтому на вопрос 2 - не для вопроса 1 и для HOT update это ничего не меняет.
На вопрос 1 - в среднем лучше конечно только измененные обновлять но не изза HOT update оптимизации а по причине более корректной работы в конкурентной среде.

Представьте себе такой сценарий:
вот ORM считал пользователя например когда он логинится
далее сразу после этого (просто совпало по времени модератор проставил пользователю статус blocked=true
после чего ORM на странице логина сохраняет запись для пользователя чтобы проставить ему logged_date=NOW() например, ну и естественно заодно и проставит ему blocked=false потому что такое значение было когда обьект из базы вычитали ;).
Модератор создает баг что пользователь не блокируется через интерфейс.
А теперь подумайте - надо ли вам такие приколы ловить в production и как именно вы их будете отлаживать?

Ну и сетевой траффик пожалейте.
И как уже правильно написали - не надо пустые update делать.

LeXa NalBatMaxim Boguk,

А можно вопрос для общего развития...

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

Без специальных мер в виде установленного https://www.postgresql.org/docs/9.6/static/functions-trigger.html на таблице
строка будет обновлена (скорее всего HOT update) и повесит все соответствующие локи.

vyegorovMaxim BogukПри обновлении код срабатывания HOT проверяет изменилось ли поле или нет НЕ ПО НАЛИЧИЮ его в update запросе а по совпадению внутреннего двоичного представления (поэтому простановка значения которая значение моля не меняет не влияет ни на HOT ни на TOAST механику причем TOAST если он не изменился даже при cold update останется в одной копии).
Поэтому на вопрос 2 - не для вопроса 1 и для HOT update это ничего не меняет.
На вопрос 1 - в среднем лучше конечно только измененные обновлять но не изза HOT update оптимизации а по причине более корректной работы в конкурентной среде.
HOT не зависит от значений, а только от факта появления новой версии записи в куче.
Т.е. если UPDATE произошел, то будет либо HOT-цепочка, либо новая "независимая" запись и все индексы надо "обновить".
Насчёт TOAST -- согласен, да.

Путаница из-за
"Даже если апдейт нужен, то не надо дёргать все поля — меньше нагрузка на индексы и тосты." - по смыслу звучит так что указание поля в update комманде не меняя значения может как то изменить для базы факт использования или нет HOT и/или toast, а это не так. По факту указание лишних полей в update дает нагрузку лишнюю только на 2 вещи - на сеть и на парсер sql (не особо заметную если в таблице не многие сотни полей).

и из-за
" Если коротко, то апдейты не затрагивающие индексированные колонки (возможно) не делают вставку в индексы" - так как понимать слово "затрагивающие" можно двояко:
или как указание этих колонок в update set списке (что не верно)
или факт реальной смены значения колонки в результате update (что верно).