* Parallélisation de la construction des index GIN
+ enfin !
* `max_parallel_maintenance_workers` = 2 (défaut)
+ on peut augmenter un peu, gain non linéaire.
Après les index B-tree depuis PostgreSQL 11, les index BRIN depuis PostgreSQL 17,
PostgreSQL 18 sait paralléliser la construction d'index GIN.
Comme pour les index B-tree, la mémoire utilisable `maintenance_work_mem`
est partagée entre les workers (sinon il y a tri sur disque),
et le nombre de processus annexes est géré par
`max_parallel_maintenance_workers` (défaut : 2).
Augmenter le paramètre `max_parallel_maintenance_workers` implique souvent
de monter `max_parallel_workers` (défaut 8), voire `max_worker_processes`
(défaut 8), et, bien sûr, d'avoir une machine avec au moins autant de processus.
`maintenance_work_mem` doit suffire à attribuer 32 Mo à chaque worker,
ce qui n'est généralement pas un souci sur les instances correctement
paramétrées.
**Exemple : index GIN d'un JSON** :
La base **personnes**
pèse en version complète 613 Mo, pour 2 Go sur disque au final. Elle peut être installée comme suit :
```bash
curl -kL https://dali.bo/tp_personnes -o /tmp/personnes.dump
createdb --echo personnes
pg_restore -v -d personnes /tmp/personnes.dump
rm -- /tmp/personnes.dump
```
La construction de l'index de 284 Mo sur le champ JSON se fait ainsi :
```sql
SET maintenance_work_mem TO '1GB';
SET max_parallel_maintenance_workers TO 2 ;
DROP INDEX pers_json_idx ;
CREATE INDEX pers_json_idx ON json.personnes USING gin (personne jsonb_path_ops);
```
| `max_parallel_maintenance_workers` | Temps de calcul |
|-----------------------------------+-------------------|
| 0 (pas de parallélisation) | 27,3 s |
| 2 (défaut) | 17,2 s |
| 4 | 15,1 s |
| 6 | 15,1 s |
Le gain est très appréciable, mais il n'est pas linéaire
avec le nombre de workers, car toutes les étapes de création
de l'index ne sont pas parallélisables.
Monter `max_parallel_maintenance_workers`
très haut n'a d'intérêt que pour les plus grosses tables.
**Exemple : index GIN pour pg_trgm** :
Dans certains cas, on hésite entre des index GIN et GiST (par exemple
pour utiliser [pg_trgm](https://dali.bo/x2_html#pg_trgm)).
Les index GiST sont censés être plus légers à maintenir,
mais la parallélisation fait pencher la balance un peu plus vers le GIN.
Cet exemple utilise la base **gutenberg** contenant de nombreux livres
(21 millions de lignes pour 3 Go sur le disque) :
```bash
curl -kL https://dali.bo/tp_gutenberg -o /tmp/gutenberg.dmp
# version réduite :
# curl -kL https://dali.bo/tp_gutenberg10 -o /tmp/gutenberg.dmp
createdb gutenberg
pg_restore -d gutenberg /tmp/gutenberg.dmp
rm -- /tmp/gutenberg.dmp
```
La construction de l'index GIN (taille : 1,3 Go)
pour l'indexation `pg_trgm` s'effectue ainsi :
```sql
SET max_parallel_maintenance_workers TO 2 ;
DROP INDEX idx_textes_trgm ;
CREATE INDEX idx_textes_trgm ON textes USING gin (contenu gin_trgm_ops);
\di+ idx_textes_trgm
```
| `max_parallel_maintenance_workers` | Temps de calcul |
|-----------------------------------+-------------------|
| 0 (pas de parallélisation) | 6 min 45 s |
| 2 (défaut) | 3 min 04 s |
| 4 | 2 min 29 s |
| 6 | 2 min 06 s |
| 8 | 2 min 05 s |
On peut donc diviser le temps de calcul par 2 ou 3,
mais ensuite un plafond est relativement vite atteint.
Pour comparaison, la création d'un index GiST, non parallélisable,
prend 11 minutes !