Używamy Postgres 9.2 w systemie Windows do przechowywania danych o niskiej częstotliwości szeregów czasowych: wstawiamy około 2000 wierszy na sekundę co sekundę 24 godziny, 7 dni w tygodniu bez przestojów. Jest taki, DELETE
który działa na stole co około 10 minut, aby utrzymać długość stołu na określoną liczbę dni. W rezultacie jest to dość stabilna 900 milionów wierszy. (Dla zainteresowanych SELECT
, INSERT
, DELETE
są wydajnych).
Dlatego DELETE
usuwanie wierszy nie zwalnia miejsca na dysku. W tym VACUUM
celu musimy biec.
Mam pytania pg_stat_user_tables
i VACUUM
wydaje się, że nigdy nie działał.
Co rozumiem z różnych dokumentów ( http://www.postgresql.org/docs/9.2/static/routine-vacuuming.html ):
- wydaje się, że mamy włączone automatyczne odkurzanie i działa na innych stołach.
- automatyczne odkurzanie nie działa
FULL
i nie powinno wymagać wyłącznego blokady na stole.
Czy ktoś ma jakieś przemyślenia, dlaczego nie działa automatyczne odkurzanie? Czy to tylko dlatego, że stół jest ciągle zajęty?
I czy warto w tym przypadku biegać VACUUM
po każdym DELETE
(który działa co 10 minut)?
Edytować:
Zapytanie za pomocą SQL z linku SO poniżej:
-[ RECORD 2 ]---+---------------------------
schemaname | stats
relname | statistic_values_by_sec
last_vacuum |
last_autovacuum |
n_tup | 932,315,264
dead_tup | 940,727,818
av_threshold | 186,463,103
expect_av | *
i surowa produkcja:
-[ RECORD 3 ]-----+---------------------------
relid | 501908
schemaname | stats
relname | statistic_values_by_sec
seq_scan | 12
seq_tup_read | 4526762064
idx_scan | 29643
idx_tup_fetch | 2544206912
n_tup_ins | 1573896877
n_tup_upd | 0
n_tup_del | 941176496
n_tup_hot_upd | 0
n_live_tup | 688858417
n_dead_tup | 940727818
last_vacuum |
last_autovacuum |
last_analyze |
last_autoanalyze | 2014-08-09 01:36:21.703+01
vacuum_count | 0
autovacuum_count | 0
analyze_count | 0
autoanalyze_count | 69
select * from pg_stat_user_tables
tę tabelę (użyj\x
w psql do ładnie sformatowanego wyjścia)