Ce se poate spune despre optimizarea planului de interogare? MVCC Există un tabel CREATE TABLE orders ( id BIGSERIAL PRIMARY KEY, status TEXT, updated_at TIMESTAMP ); și o interogare care rulează în fiecare secundă UPDATE orders SET status = 'processed', updated_at = now() WHERE id = 1; După câteva zile, observați: • dimensiunea tabelului a crescut semnificativ • interogarea SELECT * FROM orders WHERE id = 1 devine mai lentă Întrebări pentru candidat 1. De ce crește tabelul, chiar dacă rândul este întotdeauna același? 2. Ce rol joacă MVCC în această situație? 3. Ce ar trebui să rezolve această problemă?

Таблица растёт, потому что в PostgreSQL (и других СУБД с MVCC) при обновлении строки не происходит перезапись существующей записи, а создаётся новая версия строки. Старая версия остаётся в таблице до тех пор, пока не будет удалена сборщиком мусора (VACUUM). Поэтому даже при обновлении одной и той же строки физически в таблице накапливаются старые версии, что увеличивает размер таблицы.

MVCC (многоверсионность) обеспечивает изоляцию транзакций, позволяя видеть данные в состоянии на момент начала транзакции. Для этого при обновлении создаётся новая версия строки, а старая остаётся для других транзакций, которые могут её читать. Это приводит к накоплению "мертвых" версий строк.

Проблему решает регулярный запуск VACUUM (особенно VACUUM FULL или autovacuum), который удаляет устаревшие версии строк и освобождает место. Также можно настроить autovacuum для более частого срабатывания, чтобы не накапливались старые версии. В некоторых случаях помогает реорганизация таблицы или использование более подходящих стратегий обновления данных.