La table occupée n'est pas aspirée

Nous utilisons Postgres 9.2 sur Windows pour stocker des données de série temporelle basse fréquence: nous insérons environ 2000 lignes par seconde toutes les 24 heures, 7 jours par semaine sans interruption. Il y en a un DELETEqui s'exécute sur la table toutes les 10 minutes environ pour conserver la longueur de la table à un nombre fixe de jours. Cela finit par être un 900 millions de lignes assez stable. (Pour les personnes intéressées, SELECT, INSERT, DELETEsont tous performants).

En tant que tel DELETE, la suppression de lignes ne libère pas d'espace disque. Pour cela, nous devons VACUUMcourir.

J'ai interrogé le pg_stat_user_tableset VACUUMsemble n'avoir jamais couru.

Ce que je comprends de divers documents ( http://www.postgresql.org/docs/9.2/static/routine-vacuuming.html ):

il semble que le vide automatique soit activé et qu'il fonctionne sur d'autres tables.
L'aspirateur automatique ne fonctionne pas FULLet ne devrait pas nécessiter de verrou exclusif sur la table.

Quelqu'un pense-t-il pourquoi l'auto-vide ne fonctionne pas? Est-ce uniquement parce que la table est constamment occupée?

Et cela vaut la peine de courir VACUUMaprès chaque DELETEdans ce cas (qui s'exécute toutes les 10 minutes)?

Éditer:

Requête en utilisant le SQL du lien SO ci-dessous:

-[ 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       | *

et sortie brute:

-[ 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

postgresql vacuum

— Barry
source

Voir Agression Autovacuum agressive sur PostgreSQL . Il serait également intéressant d'avoir select * from pg_stat_user_tablespour ce tableau (utiliser \xen psql pour une sortie bien formatée)

— Daniel Vérité

Ce lien est utile et répond peut-être à la question - la table est trop occupée pour que l'aspirateur automatique fonctionne. @ DanielVérité J'ai mis à jour la question avec la sortie que vous avez demandée.

— Barry

Ça fait beaucoup de tuples morts! Si possible, envisagez de partitionner la table par horodatage et de supprimer les anciennes partitions au lieu de les supprimer. La principale mise en garde étant que l'index unique sur les partitions n'est pas pris en charge.

— Daniel Vérité

Le fichier journal contient-il des messages sur le vide automatique sur cette table en cours d'annulation?

— jjanes

@jjanes Non - il n'y avait aucune indication dans les journaux qu'autovacuum ait jamais démarré.

— Barry

J'examinerais le partitionnement . Si partitionné par jour, vous pouvez simplement supprimer la partition entière une fois qu'elle est trop ancienne. Il se peut même que vous n'ayez plus à passer l'aspirateur.

En outre, les performances globales peuvent augmenter, car vous n'insérez pas où vous supprimez. Il vous suffirait d'écrire le code pour créer de nouvelles partitions et supprimer les anciennes.

C'est exactement à cela que sert le partitionnement.

— SQB
source