Czy regularna ANALIZA PODCIŚNIENIA jest nadal zalecana w punkcie 9.1?

Używam PostgreSQL 9.1 na Ubuntu. Czy harmonogram jest VACUUM ANALYZEnadal zalecany, czy też autovacuum wystarcza, aby zaspokoić wszystkie potrzeby?

Jeśli odpowiedź brzmi „to zależy”, to:

• Mam obszerną bazę danych (rozmiar zrzutu skompresowanego 30 GiB, katalog danych 200 GiB)
• Wykonuję ETL do bazy danych, importując prawie 3 miliony wierszy tygodniowo
• Wszystkie tabele z najczęstszymi zmianami są dziedziczone z tabeli głównej, bez danych w tabeli głównej (dane są dzielone według tygodni)
• Tworzę zestawienia godzinowe, a stamtąd raporty dzienne, tygodniowe i miesięczne

Pytam, ponieważ harmonogram VACUUM ANALYZEma wpływ na moje raportowanie. Działa przez ponad 5 godzin i musiałem go zabić dwa razy w tym tygodniu, ponieważ miało to wpływ na regularny import bazy danych. check_postgresnie zgłasza żadnego znaczącego wzdęcia w bazie danych, więc to naprawdę nie jest problem.

Z dokumentów, auto-próżnia powinna również zadbać o zawijanie identyfikatorów transakcji. Pytanie brzmi: czy nadal potrzebuję VACUUM ANALYZE?

VACUUM jest potrzebne tylko w zaktualizowanych lub usuniętych wierszach w nietrwałych tabelach. Oczywiście robisz dużo WSTAWEK, ale z opisu nie wynika, że ​​robisz również wiele AKTUALIZACJI lub USUŃ.

Te operacje można śledzić za pomocą pg_stat_all_tableswidoku, w szczególności kolumn n_tup_updi n_tup_del. Ponadto, jeszcze bardziej do rzeczy, istnieje n_dead_tupkolumna, która mówi, dla każdej tabeli, ile rzędów należy odkurzyć. (patrz Monitorowanie statystyk w dokumencie dla funkcji i widoków związanych ze zbieraniem statystyk).

Możliwą strategią w twoim przypadku byłoby stłumienie zaplanowanego VACUUM, pilnowanie tego widoku i sprawdzanie, przy których stołach n_dead_tupznacząco rośnie. Następnie zastosuj agresywne VACUUM tylko do tych tabel. To będzie zwycięstwo, jeśli istnieją duże stoły, których wiersze nigdy nie są usuwane ani aktualizowane, a agresywne VACUUM jest naprawdę konieczne tylko na mniejszych stołach.

Ale uruchamiaj ANALIZĘ, aby optymalizator zawsze miał świeże statystyki.

W twoim pytaniu nie widzę nic, co autovacuumby się nie zajęło. W dużej mierze zależy to od wzoru twoich działań pisarskich . Wspominasz o 3 milionach nowych wierszy tygodniowo, ale INSERT(lub COPY) zazwyczaj nie tworzysz rozlanych tabel i indeksów. ( autovacuummusi tylko dbać o statystyki kolumn , mapę widoczności i niektóre drobne prace). UPDATEi DELETEsą dominującą przyczyną rozdęcia tabeli i indeksu, szczególnie przy celowaniu w losowe wiersze. Nic takiego nie widzę w twoim pytaniu.

autovacuumprzeszedł długą drogę i robi świetną robotę w Postgres 9.1 lub nowszym. Chciałbym rzucić okiem na autovacuumustawienia . Jeśli odkurzanie może zakłócać obciążenie pracą, zapoznaj się z „Opóźnieniem próżniowym opartym na kosztach” . Odkurzanie ręczne powinno być rzadkim wyjątkiem.

Jeśli masz wiele losowych UPDATE, możesz ustawić wartość FILLFACTORniższą niż 100, aby od razu umożliwić GORĄCE aktualizacje i zmniejszyć potrzebę VACUUM. Więcej informacji o aktualizacjach HOT:

• Nadmiarowe dane w instrukcjach aktualizacji

Zauważ też, że tabele tymczasowe wymagają ręcznego VACUUM& ANALYZE. Cytuję instrukcję w sprawieCREATE TABLE :

Demon autovacuum nie mają dostępu, a zatem nie może odkurzać lub analizować tabele tymczasowe. Z tego powodu odpowiednie operacje próżniowe i analizy należy wykonywać za pomocą komend SQL sesji. Na przykład, jeśli tymczasowa tabela będzie używana w złożonych zapytaniach, mądrze jest uruchomić ANALYZEtabelę tymczasową po jej zapełnieniu.

Chociaż zgadzam się, że najlepsze jest używanie funkcji automatycznych zamiast uruchamiania całej bazy danych, ale w większości przypadków konieczne jest dostrajanie tabel.

Nie do końca zgadzam się z wyborem projektu postgresów do połączenia próżni i analizy, widziałem kilka przypadków, w których bazy danych, które wykonują wiele operacji wstawiania / aktualizacji, ale niewiele operacji usuwania, nigdy nie są analizowane i zaczynają źle działać.

Rozwiązaniem jest przejście do tabel, które są często przyzwyczajone i podlegają dużym zapytaniom oraz ustawienie ustawień automatycznej analizy dla tych tabel do poziomu, w którym analizowane są raz lub co drugi dzień.

Możesz przejść do ustawień poszczególnych tabel w gui na zakładce automatycznego odkurzania, a zobaczysz tam ustawienia analizy, które możesz ustawić niezależnie od próżni.

Ustawienia kończą się w tabeli relopcji i można je zobaczyć z zapytaniem

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

i może tam być przykładowa wartość analizy agresywnej

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

Aby zobaczyć, kiedy ostatnio tabele otrzymały automatycznie przeanalizowane zapytanie

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;