то будет ли сервер перезаписывать эти строчки в смысле mvcc? а потом будет ли их чистить вакуум?
Да и да. На эту тему есть даже: https://www.postgresql.org/docs/current/functions-trigger.html (suppress_redundant_updates_trigger)
у меня обратное. хочется без блокируемого вакуум фулл пожать занимаемое пространство. не жалея диски.
Таким способом -- без шансов. Используйте pg_repack.
Ну так PostgreSQL будет сопротивляться. ;) Т.е. пытаться записать новые версии на ту же страницу, применить HOT и т.д.
вакуум обновляет карту свободного места. если делать фиктивные апдейты для записей в физическом конце таблицы, они переедут в свободное место ближе к началу. затем опять вакуум — он будет отрезать хвост таблицы, если там пустые (после вакуумирования) блоки. это используется в pgcompacttable
Насколько я помню, pgcompacttable для этого запрещает писать в соответствующие страницы как-то. А без этого postgres стремится вписать новый тапл сначала на ту жэ страницу, что и был.
не запрещает ничего
А, я глянул сейчас. Там смешнее, он забивает крайнюю страницу копиями тупла из этой жэ транзакцыи пока место не кончится.
хм, нет, зачем? одного обновления достаточно. не придумывайте
-- Update all the tuples in the range FOR _ctid IN EXECUTE _update_query USING _ctid_list LOOP IF _ctid > _max_ctid THEN _result_page := -1; EXIT _outer_loop; ELSIF _ctid >= _min_ctid THEN -- The tuple is still in the range, more updates are needed _next_ctid_list := _next_ctid_list || _ctid; END IF; END LOOP;
Ну, а как ещё? Просто update на полупустую последнюю страницу -- скорее всего, оставит всё на той жэ страницэ через слинкованные update.
Точнее -- понятно, как, переписывать движок, вводить какие-то запреты на страницы и вообще, кстати, хинты на cluster table -- чтобы тапл писался в соответствии с примерным его местом. Но это, понятно, опять куча работы.
Нет, недостаточно. См. выше (или исходники pgcompacttable, как уже показали). Ну или вот: https://dbfiddle.uk/?rdbms=postgres_13&fiddle=07f4e2fb8f828078ae7b53927aaf71ee PostgreSQL предыдущих версий тут "сдадутся" несколько быстрее, но общий принцип тот же — сервер будет стараться оптимизировать update (доступными способами) так, чтобы предотвратить использование "лишних" страниц.
И то, надо заметить, что запись выпихивают на предыдущую страницу, а не в начало...
Обсуждают сегодня