Taille des index suspecte sur oban_jobs et metrics

[thbar]

Je le note spécifiquement pour voir plus tard si ça revient.

En théorie on a un auto-vacuum sur la base, mais j'ai remarqué ceci qui m'interpelle fortement, et qui ne doit pas aider pour:

• Saturation des ressources lors des back-ups (prod-postgres) #4359
• Suivi de la taille de la base de données de production #2425

En relançant cette query, j'ai remarqué la taille des index en production en particulier sur deux tables:

table_schema	table_name	row_estimate	total	index	toast	table	total_size_share
public	oban_jobs	64381	875 MB	841 MB	3240 kB	31 MB	0.6145186079701395
public	metrics	597151	527 MB	426 MB	8192 bytes	102 MB	0.37050170161378854

Ce que la query retourne comme étant du volume d'index, est bien supérieur à la taille de la data elle-même.

⚠️ @etalab/transport-tech je vais faire un VACUUM manuel ce soir et voir si ça règle le souci, et voir aussi si ça allège la charge CPU au moment du backup (mais ça n'allègera normalement pas la taille du backup, car normalement il ne contient que les définitions des indexes).

[thbar]

J'ai fait tourner successivement:

VACUUM ANALYZE oban_jobs
VACUUM ANALYZE metrics

(et ca n'a pas suffit)

puis la version qui locke davantage:

VACUUM FULL ANALYZE oban_jobs
VACUUM FULL ANALYZE metrics

et là c'est concluant sur la taille des index:

table_schema	table_name	row_estimate	total	index	toast	table	total_size_share
public	metrics	599046	145 MB	68 MB	8192 bytes	77 MB	0.8247436409641763
public	oban_jobs	63936	31 MB	6176 kB	8192 bytes	25 MB	0.17525635903582368

Par contre, j'ai tenté sur multi_validations et j'ai eu un message d'erreur (no space left on device) temporaire.

On a en théorie du gagner 1,2GB de disque (j'irai vérifier sur Grafana).

[thbar]

Je clôture, je continuerai le ménage, mais après avoir retaillé le disque.

[thbar]

J'ai fait tourner VACUUM FULL ANALYZE multi_validation, qui bloquait avant.