Maintenance on Carnet de découvertes

Le partitionnement par hachage

Florent Jardin — Fri, 23 Apr 2021 00:00:00 +0000

Le partitionnement déclaratif a été une véritable révolution à la sortie de la version 10 de PostgreSQL en octobre 2017. La gestion des sous-tables devenait alors bien plus aisée au quotidien, simplifiant leur mise en place et leur maintenance.

Sans cesse amélioré au cours des dernières années, je me souviens encore de mon émerveillement devant la magie du partitionnement par hachage, apparu en version 11. Comment le déployer et que permet-il ? J’ai voulu m’en rendre compte dans une rapide démonstration sur le type UUID en étudiant les fonctions d’appui qui se cachent derrière le hachage des valeurs.

Un très bon choix de repli

Dès lors qu’une ou plusieurs tables dépasse le milliard de lignes, il y a fort à parier que les problèmes de performance ou de maintenance soient au rendez-vous : index volumineux, fragmentation importante, gel de l’activité pour cause de rebouclage des identifiants de transactions, difficultés à purger les données. L’apparition du partitionnement déclaratif dans PostgreSQL a permis d’y adresser des solutions avec un minimum de complexité.

La clé de partitionnement peut être définie par trois méthodes (range, list, hash) qui présentent chacunes des réponses appropriées aux besoins d’une table ou d’une fonctionnalité. Nous privilégierons une clé répartie sur un intervalle de temps pour l’archivage de données sur une date, ou bien une clé dont les valeurs sont régulées dans une liste lorsque l’on souhaite maîtriser la répartition et pouvoir la faire évoluer simplement.

La dernière méthode hash est intéressante à plusieurs égards par la confusion de la clé primaire avec la clé de partionnement et par une répartition équilibrée des données sur l’ensemble des sous-tables définies à l’avance. De manière générale, si vous n’avez pas idée de votre clé de partitionnement et que vous lisez principalement vos données sur leur clé primaire, la méthode par hachage peut être un très bon choix de repli.

Prenons une table très simple que nous découpons en cinq partitions à partir des valeurs de la clé primaire dont le type est uuid.

CREATE TABLE t1 (
 tid uuid PRIMARY KEY,
 tchar text,
 tdate timestamp without time zone
) PARTITION BY HASH (tid);

CREATE TABLE t1_0_5 PARTITION OF t1
 FOR VALUES WITH (modulus 5, remainder 0);

CREATE TABLE t1_1_5 PARTITION OF t1
 FOR VALUES WITH (modulus 5, remainder 1);

CREATE TABLE t1_2_5 PARTITION OF t1
 FOR VALUES WITH (modulus 5, remainder 2);

CREATE TABLE t1_3_5 PARTITION OF t1
 FOR VALUES WITH (modulus 5, remainder 3);

CREATE TABLE t1_4_5 PARTITION OF t1
 FOR VALUES WITH (modulus 5, remainder 4);

Avec cette configuration, l’identifiant de chaque ligne sera haché et réduit par l’opérateur modulo pour obtenir une valeur entière comprise entre 0 et 4. Insérons un petit million de lignes et observons leur répartition.

INSERT INTO t1
SELECT gen_random_uuid(), md5(g::varchar),
 current_timestamp - g * interval '1 hour'
 FROM generate_series(1, 1e6) g;

-- INSERT 0 1000000

À partir de la version 13 de PostgreSQL, la fonction gen_random_uuid() est intégrée dans le catalogue et il n’est plus nécessaire de passer par des extensions comme pgcrypto ou uuid-ossp pour générer un uuid aléatoire.

La vue pg_stat_user_tables nous indique bien un nombre de tuples équitablement insérés dans les partitions.

SELECT relname, SUM(n_live_tup) n_live_tup
 FROM pg_stat_user_tables
 GROUP BY cube(relname) ORDER BY relname;

 relname | n_live_tup
---------+------------
 t1_0_5 | 200148
 t1_1_5 | 200123
 t1_2_5 | 199964
 t1_3_5 | 200184
 t1_4_5 | 199581
 | 1000000

Le nombre de partitions est un choix crucial lors de l’initialisation de la table, ou lors de sa transformation en table partitionnée, car l’ajout de nouvelles partitions nécessite de remplacer une des sous-tables existantes par un nouvel ensemble de partitions dont le diviseur doit être un multiple du précédent.

Voyons comment scinder l’une des partitions en deux.

BEGIN;
ALTER TABLE t1 DETACH PARTITION t1_0_5;

CREATE TABLE t1_0_10 PARTITION OF t1
 FOR VALUES WITH (modulus 10, remainder 0);

CREATE TABLE t1_5_10 PARTITION OF t1
 FOR VALUES WITH (modulus 10, remainder 5);

INSERT INTO t1 SELECT * FROM t1_0_5;
-- INSERT 0 200148

DROP TABLE t1_0_5;
COMMIT;

Le contenu de l’ancienne partition t1_0_5 est déversé dans la table partitionnée et l’opérateur modulus 10 permet la redistribution des lignes dans les deux nouvelles partitions, respectivement celles dont les restes de la division sont 0 et 5. On garantit ainsi que les autres partitions ne deviennent pas leur nouvelle destination.

SELECT relname, SUM(n_live_tup) n_live_tup
 FROM pg_stat_user_tables WHERE relname like 't1%10'
 GROUP BY cube(relname) ORDER BY relname;

 relname | n_live_tup
---------+------------
 t1_0_10 | 99960
 t1_5_10 | 100188
 | 200148

Cette opération est lourde sur des données vivantes, avec des verrous de type Access Exclusive qui interdisent toutes consultations ou modifications de la table partitionnée. Les sous-tables non impliquées dans la transformation restent accessibles en lecture, pour peu qu’on puisse réaliser les SELECT sur leur nom exact de partition.

Les fonctions d’appui

La plupart des types de données sont supportés par la méthode hash à l’aide notamment des classes d’opérateur et des fonctions d’appui fournies par PostgreSQL. Par exemple, pour connaître la liste de types compatibles avec le partitionnement par hachage, il suffit de consulter le catalogue.

demo=# \dAc hash
 List of operator classes
 AM | Input type | Storage type | Operator class | Default?
------+-----------------------+--------------+---------------------+----------
 hash | aclitem | | aclitem_ops | yes
 hash | anyarray | | array_ops | yes
 hash | anyenum | | enum_ops | yes
 hash | anyrange | | range_ops | yes
 ...
 hash | uuid | | uuid_ops | yes
 hash | xid | | xid_ops | yes
 hash | xid8 | | xid8_ops | yes
(46 rows)

Lors de l’élaboration du partitionnement par hachage, la communauté a étendu les fonctions d’appui en proposant que la valeur hachée soit encodée sur 64 bits (bigint) et mélangée par salage. Dans le cas du type uuid, la fonction d’appui est uuid_hash_extended pour laquelle le deuxième argument vaut HASH_PARTITION_SEED en dur dans le code de PostgreSQL.

demo=# \dAp hash uuid*
 List of support functions of operator families
 AM | Operator family | Left type | Right type | Number | Function
------+-----------------+-----------+------------+--------+--------------------
 hash | uuid_ops | uuid | uuid | 1 | uuid_hash
 hash | uuid_ops | uuid | uuid | 2 | uuid_hash_extended

demo=# \df uuid_hash*
 List of functions
 Schema | Name | Result data type | Argument data types | Type
------------+--------------------+------------------+---------------------+------
 pg_catalog | uuid_hash | integer | uuid | func
 pg_catalog | uuid_hash_extended | bigint | uuid, bigint | func

Pour bien me rendre compte de la bonne utilisation d’une fonction d’appui pour le hachage d’une colonne particulière, j’ajoute à mon catalogue une nouvelle fonction uuid_hash_noseed qui repose sur la méthode classique uuid_hash sans salage.

CREATE OR REPLACE FUNCTION uuid_hash_noseed(value uuid, seed bigint)
 RETURNS bigint AS $$
SELECT abs(uuid_hash(value));
$$ LANGUAGE sql IMMUTABLE;

CREATE OPERATOR CLASS uuid_noseed_ops FOR TYPE uuid
 USING hash AS
 OPERATOR 1 =,
 FUNCTION 2 uuid_hash_noseed(uuid, bigint);

Le nouvel opérateur uuid_noseed_ops est défini pour utiliser la fonction créée précédemment en spécifiant le numéro d’appui 2, correspondant à la génération d’un hash encodé sur 64 bits (doc) requis pour le partitionnement. Pour valider mes hypothèses sur la distribution des lignes en fonction de leur reste de division, je crée une table t2 avec une clé primaire au format uuid dans laquelle je sépare les valeurs de hash paires et impaires.

CREATE TABLE t2 (
 tid uuid PRIMARY KEY
) PARTITION BY HASH (tid uuid_noseed_ops);

CREATE TABLE t2_0_2 PARTITION OF t2
 FOR VALUES WITH (modulus 2, remainder 0);

CREATE TABLE t2_1_2 PARTITION OF t2
 FOR VALUES WITH (modulus 2, remainder 1);

INSERT INTO t2
SELECT gen_random_uuid() FROM generate_series(1, 1e6) g;
-- INSERT 0 1000000

La suite de mon expérience m’a mené un peu plus loin que ce que j’imaginais à l’origine. Même en l’absence d’un salage avec la constante HASH_PARTITION_SEED, une autre opération au cœur de la méthode de hachage survient : hash_combine64().

/*
 * Combine two 64-bit hash values, resulting in another hash value, using the
 * same kind of technique as hash_combine(). Testing shows that this also
 * produces good bit mixing.
 */
static inline uint64
hash_combine64(uint64 a, uint64 b)
{
 /* 0x49a0f4dd15e5a8e3 is 64bit random data */
 a ^= b + UINT64CONST(0x49a0f4dd15e5a8e3) + (a << 54) + (a >> 7);
 return a;
}

Ce salage supplémentaire est fiable pour le sous-partitionnement, où l’on souhaite obtenir un hachage de plusieurs colonnes pour établir la distribution des lignes dans les partitions. Dans mon cas de test, puisque ma clé de partitionnement est seule, l’opération ne fait que commuter les bits du résultat. Ce constat avait été partagé entre deux développeurs, ce qui m’a donné la requête finale ci-dessous afin de retrouver le reste de division et de le comparer avec les noms de partitions de ma table t2.

SELECT tid, tableoid::regclass partname,
 (uuid_hash_noseed(tid, 0)::bit(64) # x'49a0f4dd15e5a8e3')::bigint % 2
 AS remainder
 FROM t2 ORDER BY tid LIMIT 10;

 tid | partname | remainder
--------------------------------------+----------+-----------
 000012e3-bf3e-4895-8dc4-adf25649680a | t2_0_2 | 0
 00003fd4-b941-4c49-afcb-6449f2ddd169 | t2_1_2 | 1
 000068b2-ce2d-4e13-9586-1ad986d31737 | t2_0_2 | 0
 00006999-696e-4c15-ac94-d1de23b89c73 | t2_1_2 | 1
 000085cb-e666-4ecb-a886-09ae86fc7d55 | t2_1_2 | 1
 00008675-2291-4c49-afd1-4b55ccbd50c1 | t2_0_2 | 0
 0000c8a1-a0fb-4e53-882d-ed9c11aba44c | t2_1_2 | 1
 0000d1fd-759a-47c5-8e87-284455b36478 | t2_0_2 | 0
 0000d3af-64da-427c-815d-b7d32f62d7a6 | t2_1_2 | 1
 0000f608-f4a2-43dd-8483-94bb317e0c95 | t2_0_2 | 0

Conclusion

Avec l’apparition du partitionnement par hachage, PostgreSQL s’est doté d’une nouvelle méthode permettant de bénéficier de tous les avantages du partitionnement déclaratif sans se soucier de la distribution logique des valeurs de la clé de partitionnement.

Bien que l’élagage de partition lors de la planification ne soit pas l’objectif de la manœuvre puisque la clé de partitionnement est par nature indexée, il devient très intéressant de bénéficier notamment d’une maintenance par VACUUM accélérée en subdivisant les données et les index sur le disque. La distribution des opérations de lecture et d’écriture sur plusieurs disques à l’aide des tablespaces est également possible depuis la version 12 et apporte son lot de solutions pour les tables très volumineuses.

Les statistiques au service du plan d'exécution

Florent Jardin — Wed, 01 Jul 2020 20:30:00 +0200

La lecture d’un plan d’exécution fait partie des meilleures armes du développeur et de l’administrateur de bases de données pour identifier les problèmes de performances. Dans un précédent article, je présentais l’intérêt de positionner un index sur les colonnes d’une table pour faciliter les recherches, notamment avec l’aide de la commande EXPLAIN.

À cette époque, je ne m’étais pas attardé sur la notion des statistiques de données, que l’on retrouve dans la plupart des moteurs du marché. Voyons de plus près ce que propose PostgreSQL pour garantir les performances de vos requêtes.

Estimer ou ne pas estimer

Une statistique de données résulte d’un calcul en arrière plan sur tout ou partie des données d’une table. Il peut s’agir de la quantité de lignes, du nombre distinct de valeurs dans une colonne, ou bien encore de la distribution des valeurs sous forme d’histogramme. Ainsi, pour chaque table et chaque colonne, il existe des données supplémentaires qui permettent au moteur d’avoir une juste estimation des données qu’il s’apprête à manipuler.

Prenons la table pgbench_history sur laquelle j’ai ajouté un index pour la colonne aid. Quel plan nous propose le moteur pour récupérer toutes les lignes dont la valeur aid est inférieure à 1 000 ?

EXPLAIN SELECT * FROM pgbench_history WHERE aid < 1000;

 QUERY PLAN
--------------------------------------------------------
 Bitmap Heap Scan on pgbench_history
 (cost=4.34..11.79 rows=9 width=116)
 Recheck Cond: (aid < 1000)
 -> Bitmap Index Scan on pgbench_history_aid_idx
 (cost=0.00..4.34 rows=9 width=0)
 Index Cond: (aid < 1000)

Le résultat qui s’affiche correspond au meilleur plan connu et repose sur un système de coût d’accès aux lignes. Le plan présentant le coût le plus faible est considéré comme le meilleur plan ; l’ensemble des nœuds le composant sera donc respecté pour récupérer le résultat final. Dans le cas de notre requête, le moteur estime que les opérations Bitmap Index et Bitmap Heap sont les moins coûteuses en performance.

Comment le moteur peut-il être certain que ce plan est le moins coûteux ? Comparons son coût d’accès total (ici 11.79) avec un autre plan pour lequel nous interdisons l’usage de l’index.

SET enable_bitmapscan = off;
EXPLAIN SELECT * FROM pgbench_history WHERE aid < 1000;

 QUERY PLAN
------------------------------------------------------------------
 Seq Scan on pgbench_history (cost=0.00..19.50 rows=9 width=116)
 Filter: (aid < 1000)

Le coût de lecture complète de la table (nœud Seq Scan) vaut 19.50, ce qui est supérieur au plan précédent. Lorsque l’on exécute un requête SQL, une partie du moteur, appelé le planificateur consolide en arrière plan une petite quantité de plans avant de ne retourner que le meilleur. Plusieurs paramètres comme enable_bitmapscan, peuvent changer complètement le comportement du planificateur en réduisant le nombre de choix possibles dans l’élaboration de ses plans.

En complément du coût, la commande EXPLAIN indique également l’estimation du nombre de lignes que retourneront les nœuds. Dans le cas des deux plans, le planificateur estime qu’il existe 9 lignes répondant au critère de recherche. Cette statistique peut être déduite des vues système pg_class et pg_stats.

SELECT s.*, c.relpages, c.reltuples
 FROM pg_stats s JOIN pg_class c ON s.tablename = c.relname
 WHERE tablename = 'pgbench_history' AND attname = 'aid' \gx

-[ RECORD 1 ]----------+------------------------------------
schemaname | public
tablename | pgbench_history
attname | aid
inherited | f
null_frac | 0
avg_width | 4
n_distinct | -0.997
most_common_vals | {66403,80979,82766}
most_common_freqs | {0.002,0.002,0.002}
histogram_bounds | {75,973,1755,… ,98037,98999,99991}
correlation | 0.047431067
most_common_elems |
most_common_elem_freqs |
elem_count_histogram |
relpages | 7
reltuples | 1000

Sans même consulter le contenu de la table pgbench_history, nous sommes en possession d’informations intéressantes. Nous apprenons que la table contient exactement 1 000 lignes (reltuples) et que la colonne aid présente un nombre de valeurs distinctes (n_distinct) qui tend vers -1, c’est-à-dire autant de valeurs uniques que de lignes dans la table.

La distribution des valeurs de la colonne aid est représentée par le tableau histogram_bounds de 100 éléments. Ces bornes divisent approximativement les valeurs dans des groupes de même taille ; comprendre que 1 % des lignes ont une valeur de colonne aid comprise entre 75 et 972, 1 % des lignes, entre 973 et 1 754, etc. On peut dès lors supposer que les valeurs possibles de la colonne aid s’étendent de 75 à 99 991.

Si l’on revient à notre critère de recherche, les lignes dont la valeur aid est inférieure à 1 000 représenteraient un peu plus de 1 % des 1000 lignes de la table, soit environ 10 lignes si toutes les valeurs étaient distinctes. L’estimation de 9 lignes proposée par la commande EXPLAIN serait donc juste.

La documentation du projet détaille en profondeur le calcul de ces estimations avec de nombreux exemples : How the Planner Uses Statistics: Row Estimation Examples.

Tout l’intérêt des statistiques est donc d’apporter suffisamment d’éléments précalculés et économes en espace disque pour que le planificateur puisse faire des estimations les plus justes possibles. Dès lors qu’une estimation est calculée, le choix du plan d’exécution le moins coûteux devient évident. Retenons que le meilleur plan doit être le moins coûteux en ressources et donc, le plus optimisé pour la requête SQL.

Qu’advient-il de notre plan si, par erreur ou hasard, les statistiques étaient erronées ou venaient à disparaître pour la colonne aid ?

DELETE FROM pg_statistic s
 WHERE starelid = 'pgbench_history'::regclass AND staattnum = (
 SELECT attnum FROM pg_attribute
 WHERE attrelid = s.starelid AND attname = 'aid'
 );

RESET enable_bitmapscan;
EXPLAIN SELECT * FROM pgbench_history WHERE aid < 1000;

 QUERY PLAN
--------------------------------------------------------------------
 Seq Scan on pgbench_history (cost=0.00..19.50 rows=333 width=116)
 Filter: (aid < 1000)

On constate qu’en l’absence de statistiques sur le critère de sélection, le plan Bitmap n’est plus le moins coûteux et n’est donc plus proposé par le planificateur. Le moteur privilégera la lecture complète de la table (Seq Scan) dont le coût est invariant.

SET enable_seqscan = off;
EXPLAIN SELECT * FROM pgbench_history WHERE aid < 1000;

 QUERY PLAN
--------------------------------------------------------
 Bitmap Heap Scan on pgbench_history
 (cost=10.86..22.02 rows=333 width=116)
 Recheck Cond: (aid < 1000)
 -> Bitmap Index Scan on pgbench_history_aid_idx
 (cost=0.00..10.77 rows=333 width=0)
 Index Cond: (aid < 1000)

L’estimation de lignes retournées peut paraître surprenante ! Il s’agit d’un calcul arbitraire défini dans la classe selfuncs.h (source) avec notamment un facteur de sélectivité qui s’applique sur le nombre total de lignes présentes dans la table. Ainsi, pour un critère d’égalité, ce facteur vaudra 0.5 % (DEFAULT_EQ_SEL=0.005) alors qu’une comparaison de non-égalité comme celle de notre exemple, vaudra 33.33 % (DEFAULT_INEQ_SEL=0.3333333333333333).

Puisque le planificateur estime devoir parcourir 333 entrées dans l’index à défaut de meilleure estimation, le coût total de ce plan est surévalué à 22.02, au lieu de 11.79 auparavant.

Collecte automatique des statistiques

Bien entendu, supprimer des statistiques n’est pas une bonne pratique et ne devrait pas être envisagé pour « changer le comportement » du planificateur. Depuis la version 8.3 de PostgreSQL, il n’y a même plus trop de raison de s’inquiéter de l’absence ou de la fraîcheur des statistiques associées à chaque colonne de vos tables : le processus autovacuum (désactivé en 8.1 et 8.2) se charge, entre autres fonctions, de parcourir régulièrement les tables de vos bases pour collecter et consolider la table pg_statistic. Il se porte ainsi garant de la pertinence des plans d’exécution.

En réalité, ce processus observe les variations de volumétrie des tables avant de déclencher l’opération ANALYZE par un processus de maintenance pour cette table. Ce mécanisme est bien plus pertinent et optimisé qu’une exécution à intervale régulier pour calculer arbitrairement les statistiques de la base.

Le seuil de déclenchement de l’autoanalyze est obtenu à l’aide d’un calcul trivial impliquant deux paramètres globaux que l’on peut surcharger, autovacuum_analyze_threshold = 50 et autovacuum_analyze_scale_factor = 0.1.

analyze threshold = analyze base threshold +
 analyze scale factor * number of tuples

Prenons l’exemple de la table pgbench_accounts qui contient un million de lignes avec une contrainte de clé primaire sur la colonne aid. La vue système pg_stat_user_tables dispose d’informations complémentaires à celles des statistiques, notamment la colonne n_mod_since_analyze qui indique la quantité de tuples ayant été modifiés depuis la dernière opération de collecte ANALYZE. Voyons son contenu après la modification d’une portion de lignes.

UPDATE pgbench_accounts SET filler = '' WHERE aid <= 10000;
-- UPDATE 10000

SELECT relname, last_autoanalyze, n_live_tup, n_mod_since_analyze
 FROM pg_stat_user_tables u
 WHERE relname = 'pgbench_accounts' \gx

-[ RECORD 1 ]-------+------------------------------
relname | pgbench_accounts
last_autoanalyze | 2020-06-18 15:12:55.224493+02
n_live_tup | 1000000
n_mod_since_analyze | 10000

Ici, seul 1 % de la table a subi un changement et le mécanisme de collecte automatique des statistiques semble ne pas s’être déclenché. En effet, le seuil de déclenchement pour cette table serait plutôt de 100 050 lignes (50 + 0.1 * 1000000). Recommençons avec un plus large échantillon et observons les traces d’activité du processus autovacuum.

ALTER SYSTEM SET log_min_messages = debug2;
ALTER SYSTEM SET log_autovacuum_min_duration = 0;
SELECT pg_reload_conf();

UPDATE pgbench_accounts SET filler = '' WHERE aid <= 90051;
-- UPDATE 90051

SELECT relname, last_autoanalyze, n_live_tup, n_mod_since_analyze
 FROM pg_stat_user_tables u
 WHERE relname = 'pgbench_accounts' \gx

-[ RECORD 1 ]-------+------------------------------
relname | pgbench_accounts
last_autoanalyze | 2020-06-30 17:44:22.424363+02
n_live_tup | 1000000
n_mod_since_analyze | 0

Comme attendu, un traitement ANALYZE s’est exécuté et a mis à jour les données de la vue pg_stat_user_tables, mettant à zéro la colonne n_mod_since_analyze jusqu’au prochain déclenchement. Côté trace d’activité, le mode debug2 écrit une série d’événements tels que les seuils calculés de la table, le démarrage et la fin du traitement par le worker dédié.

DEBUG: autovacuum: processing database "demo"
DEBUG: pgbench_accounts: vac: 100051 (threshold 200050),
 anl: 100051 (threshold 100050)
DEBUG: analyzing "public.pgbench_accounts"
LOG: automatic analyze of table "demo.public.pgbench_accounts"
 system usage: CPU: user: 0.09 s, system: 0.00 s, elapsed: 0.25 s

Estimer la prochaine heure de la collecte

Dans la plupart des cas, les paramètres associés au mécanisme d’autovacuum sont adaptés à la plupart des tables et assurent une fréquence correcte du calcul des statistiques. Cependant, au-delà d’une certaine volumétrie, une table peut présenter des incohérences entre son contenu et ses statistiques.

La modification de 10 % de la table pgbench_accounts pourrait prendre des jours voire des semaines avant que ne survienne le traitement autoanalyze. Il est donc de la responsabilité du développeur ou du DBA de surveiller l’accroissement de l’indicateur n_mod_since_analyze pour éviter que les statistiques ne soient trop décorrélées du contenu.

Pour s’en assurer, je crée deux fonctions dans ma base pour récupérer respectivement les options de stockage d’une table (reloptions) ou à défaut, les paramètres d’instance, ainsi que le calcul du seuil de déclenchement sur la base de la formule précédente. La seconde fonction s’assure notamment que le mécanisme de collecte automatique n’est pas désactivé (autovacuum_enabled = off).

CREATE OR REPLACE FUNCTION get_reloption(reloptions text[], name text)
RETURNS text LANGUAGE sql
AS $$
 SELECT coalesce(min(option_value), current_setting(name))
 FROM pg_options_to_table(reloptions) WHERE option_name = name;
$$;

CREATE OR REPLACE FUNCTION get_anl_threshold(o oid)
RETURNS float LANGUAGE sql
AS $$
 SELECT get_reloption(reloptions, 'autovacuum_analyze_threshold')::int +
 get_reloption(reloptions, 'autovacuum_analyze_scale_factor')::float *
 c.reltuples
 FROM pg_class c
 WHERE oid = o AND NOT EXISTS (
 SELECT 1 FROM pg_options_to_table(c.reloptions)
 WHERE option_name = 'autovacuum_enabled' AND option_value = 'off'
 )
$$;

Avec les résultats de ces fonctions, je peux construire une requête plus évoluée qui estime l’heure du prochain déclenchement en fonction de nombre de modification et de la dernière collecte.

SELECT relname, n_live_tup, n_mod_since_analyze,
 get_anl_threshold(relid) threshold, last_autoanalyze,
 current_timestamp +
 (1 -
 CASE WHEN n_mod_since_analyze = 0 THEN null
 WHEN n_mod_since_analyze > get_anl_threshold(relid) THEN 1
 ELSE n_mod_since_analyze / get_anl_threshold(relid) END) *
 (current_timestamp - last_autoanalyze) next_autoanalyze
FROM pg_stat_user_tables WHERE relname = 'pgbench_accounts' \gx

-[ RECORD 1 ]--------+------------------------------
relname | pgbench_accounts
n_live_tup | 1000000
n_mod_since_analyze | 0
threshold | 100050
last_autoanalyze | 2020-07-01 15:07:40.134444+02
next_autoanalyze |

UPDATE pgbench_accounts SET filler = '' WHERE aid <= 25000;
-- UPDATE 25000

-[ RECORD 1 ]--------+------------------------------
relname | pgbench_accounts
n_live_tup | 1000000
n_mod_since_analyze | 25000
threshold | 100050
last_autoanalyze | 2020-07-01 15:07:40.134444+02
next_autoanalyze | 2020-07-01 18:16:43.734491+02

La commande ALTER TABLE suivante permet de modifier les options de stockage de la table, et d’ajuster le seuil du déclenchement automatique de la collecte. À vous de voir si l’activité sur votre table le justifie !

ALTER TABLE pgbench_accounts SET (
 autovacuum_analyze_scale_factor = 0.01,
 autovacuum_analyze_threshold = 0
);

-[ RECORD 1 ]--------+------------------------------
relname | pgbench_accounts
n_live_tup | 1000000
n_mod_since_analyze | 25000
threshold | 10000
last_autoanalyze | 2020-07-01 15:07:40.134444+02
next_autoanalyze | 2020-07-01 17:04:34.038917+02

-[ RECORD 1 ]--------+------------------------------
relname | pgbench_accounts
n_live_tup | 1000000
n_mod_since_analyze | 0
threshold | 10000
last_autoanalyze | 2020-07-01 17:04:41.987032+02
next_autoanalyze |

Conclusion

Les statistiques jouent un rôle essentiel dans les performances d’un moteur relationnel comme PostgreSQL. Réussir à les maintenir pertinentes est la clé dans la gestion au quotidien du système. Avec mon exposé, j’espère vous avoir démontré qu’il n’est pas nécessaire de rafraîchir toutes les statistiques, mais seulement celles dont le seuil n’est plus adapté.

Dans un genre similaire, un récent article de Hubert « depesz » Lubaczewski présente une série de requêtes permettant d’identifier les tables nécessitant une action de maintenance (vacuum ou analyze) dans le cas où la routine automatique ne fait pas correctement son travail. Ce genre de petites astuces peuvent sauver des vies… (euh) des plans d’exécution !

Les liens physiques avec pg_upgrade

Florent Jardin — Thu, 23 Apr 2020 15:30:00 +0200

La création d’un lien sous Unix se réalise avec les commandes ln ou cp. Cette action permet de lier deux fichiers vers la même donnée et de rendre disponible une ressource par l’intermédiaire de l’un ou de l’autre de ces fichiers.

Cependant, les opérations diffèrent selon le type de ce lien. Le plus connu reste le symlink, le lien symbolique. Mais qu’en est-il des autres ? Comment se caractérisent-ils et dans quels contextes ? En vrai, qu’est-ce qu’un inode ? Et PostgreSQL dans tout ça ? Autant de petites questions de curiosité que j’aborde avec vous dans cet article !

Parlons d’abord du lien symbolique

Pour faire simple, on peut comparer le lien symbolique à un raccourci Windows. Il s’agit d’un pointeur vers un fichier ou un répertoire qui permet toutes les opérations simples comme la lecture ou l’écriture.

Par exemple, pour une instance PostgreSQL, il est possible de déporter le répertoire des fichiers WAL sur un autre montage à l’aide d’un lien symbolique. Cette opération nécessite un arrêt du service et la copie des fichiers vers le nouveau montage, comme suit :

# à réaliser avec le compte root
systemctl stop postgresql-12.service

# créer le nouveau répertoire en préservant les permissions
install --owner=postgres --group=postgres --mode=700 -d /u01/pg_wal/12
mv /var/lib/pgsql/12/data/pg_wal/* /u01/pg_wal/12/

# créer le lien vers le nouveau répertoire
rmdir /var/lib/pgsql/12/data/pg_wal
ln --symbolic /u01/pg_wal/12 /var/lib/pgsql/12/data/pg_wal

# et redémarrer l'instance
systemctl start postgresql-12.service

Le lien ainsi obtenu par la commande ln --symbolic se présente comme une fausse copie du répertoire d’origine, permettant aux données d’être consultées à plusieurs endroits sans risque d’être dupliquées. La commande stat nous donne de précieuses informations à son sujet :

# FORMAT="File = %N\nType = %F\nOwner = %U:%G\nAccess = %A\nInode = %i\n"
# stat --printf="$FORMAT" /var/lib/pgsql/12/data/pg_wal
File = ‘/var/lib/pgsql/12/data/pg_wal’ -> ‘/u01/pg_wal/12’
Type = symbolic link
Owner = root:root
Access = lrwxrwxrwx
Inode = 33725146

Il apparait que son propriétaire est root, que son accès est ouvert à tous, et que l’inode qui lui est associé vaut 33919915. Qu’en est-il de répertoire contenant les journaux de transactions ?

# stat --printf="$FORMAT" /u01/pg_wal/12
File = ‘/u01/pg_wal/12’
Type = directory
Owner = postgres:postgres
Access = drwx------
Inode = 33867963

Les deux fichiers sont bien distincts et présentent des différences notables, comme les propriétaires et les droits d’accès. En réalité, Unix propose sept types de fichiers et chacun présente des caractéristiques et comportements que lui sont propres. On retrouve ainsi les fichiers, répertoires, liens symboliques, mais aussi les named pipes, les sockets, les devices ou les doors.

Le dernier attribut que remonte ma commande stat correspond au inumber ou numéro inode. Il s’agit d’un identifiant unique sur le système de fichiers permettant de retrouver toutes les métadonnées du fichier dans une table d’inodes. Nous avions vu à l’instant les droits et le propriétaire, l’inode permet également de stocker les horodatages de création ou de modification ainsi que l’adresse physique des données du fichier sur le disque.

Ainsi, pour chaque fichier sur notre système lui est associé un inode. La représentation suivante permet donc de comprendre la relation entre un lien symbolique et un répertoire.

Le mode --link de `pg_upgrade`

Les choses sont devenues passionnantes lorsque j’ai découvert la notion de lien physique, ou hardlink, qu’il était possible de créer entre deux fichiers. Ce n’est en rien une nouveauté, car inclu dans les systèmes Unix depuis longtemps mais ça m’a permis de comprendre davantage l’intérêt des fameux inodes.

Puisqu’un exemple concret parle toujours de lui-même, je propose d’étudier la méthode de migration de données d’une version 9.6 vers une version 12 de PostgreSQL avec l’outil pg_upgrade. Ce dernier propose l’option --link pour réduire le temps de migration des données sans copier les fichiers d’une instance à l’autre. Bien sûr, ce n’est pas le comportement par défaut.

La distribution CentOS 7 est utilisée pour la démonstration.
Le paquet postgresql12-server doit être installé au préalable.

# la routine setup permet la création du fichier de service ainsi
# que l'initilisation d'un répertoire de données minimaliste
/usr/pgsql-12/bin/postgresql-12-setup initdb postgresql-12

# durant la migration, l'instance 9.6 doit être arrêtée
systemctl stop postgresql-9.6.service

export PGDATAOLD=/var/lib/pgsql/9.6/data
export PGDATANEW=/var/lib/pgsql/12/data
export PGBINOLD=/usr/pgsql-9.6/bin
export PGBINNEW=/usr/pgsql-12/bin
$PGBINNEW/pg_upgrade --link --verbose

# extrait du déroulement
mappings for database "prod":
public.pgbench_accounts: 16397 to 16391

linking "/var/lib/pgsql/9.6/data/base/16384/16397" to
 "/var/lib/pgsql/12/data/base/16402/16391"
linking "/var/lib/pgsql/9.6/data/base/16384/16397_fsm" to
 "/var/lib/pgsql/12/data/base/16402/16391_fsm"
linking "/var/lib/pgsql/9.6/data/base/16384/16397_vm" to
 "/var/lib/pgsql/12/data/base/16402/16391_vm"

L’outil pg_upgrade est composé d’une série d’opération de contrôle, de copies de fichiers, d’arrêt/démarrage des instances et d’une remise à zéro des journaux de transactions avec pg_resetwal. Les lignes ci-dessus illustrent le mode --link lors de notre migration, avec la création d’un lien entre les deux versions du fichier de la table pgbench_accounts.

La méthode employée peut être consultée dans les sources de pg_upgrade et repose sur la méthode link. Regardons en détail les métadonnées des fichiers de données de la table pgbench_accounts dans les deux répertoires.

# FORMAT="${FORMAT}Links = %h\n"
# stat --printf="$FORMAT" /var/lib/pgsql/9.6/data/base/16384/16397
File = ‘/var/lib/pgsql/9.6/data/base/16384/16397’
Type = regular file
Owner = postgres:postgres
Access = -rw-------
Inode = 101132106
Links = 2

# stat --printf="$FORMAT" /var/lib/pgsql/12/data/base/16402/16391
File = ‘/var/lib/pgsql/12/data/base/16402/16391’
Type = regular file
Owner = postgres:postgres
Access = -rw-------
Inode = 101132106
Links = 2

Au niveau du système, les fichiers sont strictement similaires. Pour dire vrai, il s’agit des mêmes inodes. Les métadonnées sont communes aux deux fichiers et les blocs de données de la table pgbench_accounts résident à la même adresse physique.

À la différence du lien symbolique, ce type de lien rattache un fichier non pas à un autre fichier, mais au numéro d’inode d’un autre fichier. L’attribut Links de ma commande stat correspond au nombre de liens sur l’inode en question. Une représentation de cette relation pourait être la suivante :

Les avantages sont doubles dans le cas d’une migration majeure :

Temps de copie des données quasi-nul : le modèle de données est importé dans la nouvelle instance et les fichiers de données sont liés à ceux de la version précédente ;
Économie d’espace disque : la migration n’a pas besoin du double d’espace disque.

En contrepartie :

Pas de retour arrière : chacune des deux instances disposent de fichiers internes comme les journaux de transactions ou le fichier de contrôle, rendant incompatibles les fichiers de données à l’une des deux instances dès lors que l’autre a démarré après la migration.

Fin de vie d’une donnée liée

L’une de mes questions à l’issue d’une migration par pg_upgrade a été : « Mais que se passe-t-il si nous ne supprimons pas l’ancien répertoire de données ? ». Puisque la donnée est référencée par la nouvelle instance, toutes les nouveautés y seront stockées et il n’y a pas de risque pour l’espace disque. Vraiment ?

Comme nous le voyions précédemment, les données de la table pgbench_accounts sont accessibles à travers le numéro d’inode 101132106. Les deux liens pointent vers la même adresse physique et la même allocation d’espace disque, ici 13 Mo.

# du -lh 9.6/data/base/16384/16397 12/data/base/16402/16391
13M 9.6/data/base/16384/16397
13M 12/data/base/16402/16391

Il est possible au cours de la vie d’une table de voir son identifiant relfilenode varier au moment de la réécriture du fichier sous un nom différent. Le cas se présente lorsque l’on souhaite déplacer la table dans un autre tablespace, quand il faut la défragmenter avec VACUUM FULL, ou lors de la restauration d’un dump. Ces opérations réalisent toute une reconstruction de la table, avec le déplacement des lignes dans un nouveau fichier.

SELECT pg_relation_filepath('pgbench_accounts');
-- pg_relation_filepath
-- ----------------------
-- base/16402/16391

VACUUM FULL pgbench_accounts;
CHECKPOINT;

SELECT pg_relation_filepath('pgbench_accounts');
-- pg_relation_filepath
-- ----------------------
-- base/16402/16435

Ici, la défragmentation reconstruit la table dans un nouveau fichier 16435. L’instruction CHECKPOINT permet d’écrire sur disque la totalité des nouveaux blocs et d’actualiser l’usage des fichiers, supprimant en principe les anciens fichiers de données.

# du -lh 9.6/data/base/16384/16397 12/data/base/16402/16435
0 9.6/data/base/16384/16397
13M 12/data/base/16402/16435

# FORMAT="File = %n\nInode = %i\n"
# stat --printf="$FORMAT" 9.6/data/base/16384/16397 
File = 9.6/data/base/16384/16397
Inode = 101132106

# stat --printf="$FORMAT" 12/data/base/16402/16435
File = 12/data/base/16402/16435
Inode = 34082173

Le nouveau fichier de notre table pour l’instance 12 pèse toujours 13 Mo, le fichier maintenu par le lien physique de la version précédente a été vidé lors de l’opération VACUUM FULL et pèse à présent zéro octet. Mais il n’a pas été supprimé ! Nous nous retrouvons avec un fichier et son inode en trop sur le serveur.

Sur un système de fichiers, le nombre maximal de fichiers que l’on peut créer est défini par la quantité d’inodes disponibles, alors autant faire le ménage dès que possible pour ne pas atteindre cette limite. D’autant plus que la suppression du répertoire 9.6/data est proposée à la fin de la migration par l’outil pg_upgrade et ne présente aucun risque !

Conclusion

Apparu en version 9.0, l’outil pg_upgrade est une petite usine qui simule un import/export des structures d’une instance complète, avec la capacité de copier ou lier les anciens fichiers, de façon bien plus rapide qu’une insertion massive avec l’instruction COPY de pg_restore. C’est une solution de choix lorsque l’on migre d’une version majeure à l’autre sur un même serveur, notamment pour le gain de temps non négligeable que propose l’option --link.

Avec la version 12, l’outil propose une nouvelle option --clone et s’appuie sur la notion de liens « par référence » (ou reflinks), conçus initialement sur les systèmes de fichiers supportant la copie sur écriture. La documentation précise que la copie des fichiers est pratiquement instantanée et n’affecte pas l’ancienne instance.

Peut-être l’occasion de creuser le sujet dans un prochain article ?

Maintenance on Carnet de découvertes

Le partitionnement par hachage

Un très bon choix de repli

Les fonctions d’appui

Conclusion

Les statistiques au service du plan d'exécution

Estimer ou ne pas estimer

Collecte automatique des statistiques

Estimer la prochaine heure de la collecte

Conclusion

Les liens physiques avec pg_upgrade

Parlons d’abord du lien symbolique

Le mode --link de pg_upgrade

Fin de vie d’une donnée liée

Conclusion

Le mode --link de `pg_upgrade`