Ze względu na PostgreSQL MVCC UPDATE skutecznie przypomina DELETE plus INSERT . Z godnym uwagi wyjątkiem wartości prażonych - patrz:
- Czy Postgres przepisuje cały wiersz podczas aktualizacji?
(I drobne różnice dla krotek tylko dla sterty - DELETE + INSERT uruchamia nowy łańcuch HOT - ale nie ma to żadnego wpływu na sprawę.)
Aby być precyzyjnym, „usunięty” wiersz jest po prostu niewidoczny dla każdej transakcji rozpoczynającej się po popełnieniu usunięcia i odkurzany później. Dlatego po stronie bazy danych, w tym manipulacji indeksem, w efekcie nie ma różnicy między tymi dwoma stwierdzeniami. (Obowiązują wyjątki, czytaj dalej.) Zwiększa nieco ruch w sieci (w zależności od danych) i wymaga trochę analizy.
Studiowałem aktualizacje HOT trochę po wejściu @araqnid i przeprowadziłem kilka testów. Aktualizacje kolumn, które w rzeczywistości nie zmieniają wartości, nie mają znaczenia w ogóle, jeśli chodzi o aktualizacje HOT. Moja odpowiedź jest aktualna. Zobacz szczegóły poniżej.
Dotyczy to również upieczonych atrybutów, ponieważ te również nie są zmieniane, chyba że wartości w rzeczywistości się zmienią .
Jednak , jeśli używasz wyzwalaczy na kolumnę (wprowadzone wraz ze stroną 9.0), może to mieć niepożądane skutki uboczne!
Cytuję instrukcję dotyczącą wyzwalaczy:
... polecenie takie jak UPDATE ... SET x = x ... uruchomi wyzwalacz w kolumnie x , mimo że wartość kolumny się nie zmieniła .
Pogrubiony nacisk na moje.
Warstwy abstrakcji są dla wygody. Są przydatne dla programistów niepiśmiennych SQL lub jeśli aplikacja musi być przenośna między różnymi RDBMS. Z drugiej strony, potrafią ubić wydajność i wprowadzić dodatkowe punkty awarii. Unikam ich wszędzie, gdzie to możliwe.
GORĄCE (tylko stosy) aktualizacje
Krotki typu Heap-Only zostały wprowadzone w Postgres 8.3, z ważnymi ulepszeniami w 8.3.4 i 8.4.9.
Informacje o wydaniu dla Postgres 8.3:
UPDATE s i DELETE s pozostawiają martwe krotki, tak jak nieudane INSERT s.Poprzednio tylko VACUUM może odzyskać przestrzeń zajmowaną przez martwe krotki. WithHOT martwa przestrzeń krotki może być automatycznie odzyskana w momencie INSERT lub UPDATE jeśli w indeksowanych kolumnach nie wprowadzono żadnych zmian . Pozwala to na bardziej spójną wydajność. Ponadto HOT unika dodawania zduplikowanych wpisów w indeksie.
Podkreśl mój. A „bez zmian” obejmuje przypadki, w których kolumny są aktualizowane o tę samą wartość, co już posiadają. właściwie przetestowałem , czego nie byłem pewien.
Ostatecznie potwierdza to obszerny README.HOT w kodzie źródłowym.
Toastowane kolumny również nie stoją na przeszkodzie GORĄCYM aktualizacjom. Zaktualizowana krotka HOT po prostu łączy się z tą samą, niezmienioną krotką(ami) w rozwidleniu toastowym relacji. Aktualizacje HOT działają nawet z wypieczonymi wartościami na liście docelowej (w rzeczywistości zmienionymi lub nie). Jeśli toastowane wartości zostaną zmienione, pociąga to za sobą oczywiście zapisy do rozwidlenia relacji toastu. To wszystko też przetestowałem.
Nie wierz mi na słowo, przekonaj się sam. Postgres udostępnia kilka funkcji do sprawdzania statystyk. Uruchom UPDATE ze wszystkimi kolumnami i bez nich i sprawdź, czy ma to jakiekolwiek znaczenie.
-- Number of rows HOT-updated in table:
SELECT pg_stat_get_tuples_hot_updated('table_name'::regclass::oid)
-- Number of rows HOT-updated in table, in the current transaction:
SELECT pg_stat_get_xact_tuples_hot_updated('table_name'::regclass::oid)
Lub użyj pgAdmin. Wybierz swoją tabelę i sprawdź zakładkę „Statystyki” w oknie głównym.
Należy pamiętać, że aktualizacje HOT są możliwe tylko wtedy, gdy jest miejsce na nową wersję krotki na tej samej stronie głównego rozwidlenia relacji. Jednym prostym sposobem na wymuszenie tego warunku jest testowanie za pomocą małej tabeli, która zawiera tylko kilka wierszy. Rozmiar strony to zazwyczaj 8k, więc na stronie musi być wolne miejsce.
