SG
UPDATE t
SET f = 1
WHERE
id = $id
AND
f <> 1 -- !!!!!
В большинстве проектов это разгрузит сервер существенно.
Если подходить более комплексно, то первое, о чем можно подумать - это партиционирование таблиц. А надеюсь, что апдейтится не primary key, а значит на каждую партицию можно иметь свой независимый индекс, который не будет блоатиться. В свежих версиях PG хоть и не изобрели автосоздания партишенов, но по крайней мере есть DEFAULT партишен, куда попадет все, если подходящий партишен не найден.
Там дальше появляются еще бенефиты - партишены можно раскидать по разным дискам и получить дополнительных иопсов.
Т.е. идея в том, что не все данные постоянно перетряхиваются. Если перетряхиваются все и их много, возможно, есть смысл подумать об архитектуре более детально.
Когда мы парсили блокчейн, с индексированием все было больно по понятным причинам. В определенный момент до нас дошло, что переиндексировать все не нужно. надо разделить данные на head и tail и раз в месяц, например, данные скидывать из одного в другой. Т.е. head был всегда только на чтение.
Если зайти совсем далеко, можно head и tail разложить по разным базам и делать map-reduce на стороне приложения. Но это по понятным причинам не всем подходит