web-dev-qa-db-fra.com

L'aspirateur est-il complets nécessaire sur une table de goutte / une approche tronquée pour une datawarehouse

Nous mettons à jour une datawarehouse sur une base hebdomadaire en utilisant une série de

TRUNCATE source_table1 
COPY source_table1 FROM [...]

... pour l'importation de données et:

DROP TABLE IF EXISTS my_table
CREATE TABLE my_table AS SELECT [...]

pour les mises à jour de table.

Nous mettons fin à notre processus de mise à jour avec un VACUUM FULL [VERBOSE] ANALYZE, car, comme la documentation suggère, VACUUM devrait être effectué lorsqu'une part importante des uples a été mise à jour ou supprimée. Ici, comme il s'agit d'une part de 100% pour toutes les tables, nous avons raisonnablement pensé que VACUUM devrait être appliqué.

Comme nous voyons l'Output de l'option Verbose, il semble que PostgreSQL n'ait pas grand chose à faire, car chaque table VACUUMed donne:

INFO:  vacuuming "public.table345"
INFO:  "table345": found 0 removable, 9831703 nonremovable row versions in 62538 pages
DETAIL : 0 dead row versions cannot be removed yet.

Je suppose que au contraire ANALYZE est plus que contribuant à mettre à jour les statistiques internes. La plupart des tables sont des rangées de 10 à 100 m.

Mais nous nous demandions si VACUUM FULL ou juste VACUUM étaient vraiment nécessaires dans ce cas?

(Ou peut être le processus de mise à jour entier (chute/Create Table comme) n'est pas la bonne façon de le faire?)

postgresqlvacuumpostgresql-9.6
3
ant1j

Point sur tronquage/copie

Remarque non liée, en fonction du niveau WAL, enveloppez le TRUNCATE _ et COPY dans la même transaction Things May aller plus vite, car WAL sera sauté. En outre, les CTA sauteront toujours le plus Wal.

En niveau minimal, la journalisation de certaines opérations en vrac peut être ignorée en toute sécurité, ce qui peut rendre ces opérations beaucoup plus rapidement (voir la section 14.4.7). Opérations dans lesquelles cette optimisation peut être appliquée inclure source

  • créer une table comme
  • Créer index
  • GROUPE
  • Copier dans des tables créées ou tronquées dans la même transaction 
    BEGIN;
      TRUNCATE source_table1 
      COPY source_table1 FROM [...]
    COMMIT;

Problème de VACUUM FULL

  1. Il n'y a pas besoin de faire un VACUUM FULL sur une nouvelle table. La table est déjà nouvelle dans ces transactions, il n'est donc pas nécessaire de le réécrire, car FULL fait. Il n'y a pas non plus besoin de VACUUM It car il n'y a pas de rangées mobiles que l'aspirateur agira. Quand vous courez VACUUM FULL VERBOSE, vous ne pouvez voir que rien était amovible et aucune ligne de rangée morte n'a été supprimée. VACUUM FULL peut être utile si

    1. vous déposez INSERTS si une table Temp et les ajoutez en lots dans une table sale. Ensuite, cela peut souvent payer à la fin du processus.
    2. vous exécutez UPDATE sur un grand lot car UPDATE génère de nouvelles lignes forçantes VACUUM pour marquer plus tard les anciennes lignes comme mortes.

  2. Un simple ANALYZE fonctionnera bien. Cela mettra à jour le statistiques sur la table.

1
Evan Carroll