* `pg_stat_database`
- nouvelles colonnes `parallel_workers_to_launch` et `parallel_workers_launched`
* `pg_stat_all_tables`
- plusieurs colonnes indiquant le temps passé sur les opérations VACUUM et
ANALYZE
* `pg_stat_io`
- indique l'activité en octets (et non en blocs)
- indique l'activité sur les journaux de transactions
- `track_wal_io_timing` à activer pour avoir les durées
* `pg_stat_wal`
- suppressions des colonnes `read` et `sync`
* `pg_stat_checkpointer`
- nouvelles colonnes `num_done` et `slru_written`
**Vue pg_stat_database**
La vue `pg_stat_database` comporte deux nouvelles colonnes.
`parallel_workers_to_launch` indique le nombre total de _workers_ de
parallélisation à lancer, et `parallel_workers_launched` le nombre total de
_workers_ de parallélisation lancés. Cela devrait permettre de savoir si la
parallélisation est fréquemment demandée (première colonne avec une valeur
haute) et si la configuration est suffisante (première et deuxième colonnes
de valeurs équivalentes). Sinon il faut peut-être ajuster
les paramètres du parallélisme comme `max_parallel_workers_per_gather`
ou `max_parallel_workers` (voir plus loin).
**Vue pg_stat_all_tables**
La table `pg_stat_all_tables` (et par conséquent ses deux variantes
`pg_stat_sys_tables` et `pg_stat_user_tables`) se voit
ajouter quatre nouvelles colonnes :
* `total_vacuum_time`, durée totale des opérations `VACUUM` manuelles sur
cette table ;
* `total_autovacuum_time`, durée totale des opérations `VACUUM` automatiques
sur cette table ;
* `total_analyze_time`, durée totale des opérations `ANALYZE` manuelles sur
cette table ;
* `total_autoanalyze_time`, durée totale des opérations `ANALYZE` automatiques
sur cette table.
Il est à noter qu'il n'est pas nécessaire d'activer `track_io_timing` pour que
cette durée soit comptabilisée.
Voici un exemple concernant uniquement la colonne `total_vacuum_time` :
```
create table t1(c1 integer);
alter table t1 set (autovacuum_enabled=off);
insert into t1 select generate_series(1, 10_000_000);
select relname, total_vacuum_time from pg_stat_all_tables where relname='t1';
┌─────────┬───────────────────┐
│ relname │ total_vacuum_time │
├─────────┼───────────────────┤
│ t1 │ 0 │
└─────────┴───────────────────┘
(1 row)
vacuum t1;
VACUUM
Time: 2225.883 ms (00:02.226)
select relname, total_vacuum_time from pg_stat_all_tables where relname='t1';
┌─────────┬───────────────────┐
│ relname │ total_vacuum_time │
├─────────┼───────────────────┤
│ t1 │ 2225 │
└─────────┴───────────────────┘
(1 row)
```
Comme la table n'a jamais été traitée, elle doit être entièrement lue, ce qui
cause un long traitement. Les 2225 ms chronométrées par `psql` sont bien visibles
dans la vue statistique. Un deuxième `VACUUM` devrait être bien plus rapide.
```
vacuum t1;
VACUUM
Time: 0.975 ms
select relname, total_vacuum_time from pg_stat_all_tables where relname='t1';
┌─────────┬───────────────────┐
│ relname │ total_vacuum_time │
├─────────┼───────────────────┤
│ t1 │ 2226 │
└─────────┴───────────────────┘
(1 row)
```
C'est bien le cas, il n'a pris qu'une seule milliseconde, qui se trouve bien
comptabilisée dans la vue statistique.
Supprimons un bon lot de lignes pour qu'il ait du travail :
```
delete from t1 where c1<100000;
vacuum t1;
VACUUM
Time: 5.012 ms
select relname, total_vacuum_time from pg_stat_all_tables where relname='t1';
┌─────────┬───────────────────┐
│ relname │ total_vacuum_time │
├─────────┼───────────────────┤
│ t1 │ 2231 │
└─────────┴───────────────────┘
(1 row)
```
Là aussi, nous pouvons constater que ce nouveau traitement a été pris en compte
dans la vue statistique.
**Vues pg_stat_io et pg_stat_wal**
La vue `pg_stat_io` intègre maintenant des statistiques sur les entrées/sorties
disque des processus _WAL writer_, _WAL receiver_ et _WAL summarizer_, ainsi que
les processus de communication avec les clients.
Avec la requête suivante :
```sql
select backend_type, object, count(*)
from pg_stat_io
where object='wal' or backend_type like 'wal%'
group by 1, 2
order by 1, 2;
```
Voici les statistiques en version 17 :
```
┌──────────────┬───────────────┬───────┐
│ backend_type │ object │ count │
├──────────────┼───────────────┼───────┤
│ walsender │ relation │ 4 │
│ walsender │ temp relation │ 1 │
└──────────────┴───────────────┴───────┘
```
Et celles en version 18 :
```
┌─────────────────────┬───────────────┬───────┐
│ backend_type │ object │ count │
├─────────────────────┼───────────────┼───────┤
│ autovacuum launcher │ wal │ 2 │
│ autovacuum worker │ wal │ 2 │
│ background worker │ wal │ 2 │
│ background writer │ wal │ 2 │
│ checkpointer │ wal │ 2 │
│ client backend │ wal │ 2 │
│ io worker │ wal │ 2 │
│ slotsync worker │ wal │ 2 │
│ standalone backend │ wal │ 2 │
│ startup │ wal │ 2 │
│ walreceiver │ wal │ 2 │
│ walsender │ relation │ 5 │
│ walsender │ temp relation │ 1 │
│ walsender │ wal │ 2 │
│ walsummarizer │ wal │ 2 │
│ walwriter │ wal │ 2 │
└─────────────────────┴───────────────┴───────┘
```
Le nombre d'informations est bien plus important. Certaines informations étant
disponibles sur `pg_stat_io` et `pg_stat_wal`, elles ont été supprimées de cette
dernière. Il s'agit des colonnes `read` et `sync`.
Pour terminer sur la vue `pg_stat_io`, l'activité est maintenant indiqué en
octets et non plus en blocs.
**Vue pg_stat_checkpointer**
Enfin, la vue `pg_stat_checkpointer` dispose de deux nouvelles colonnes.
`num_done` indique le nombre de _checkpoints_ réalisés, et `slru_written`
indique le nombre de blocs écrits à partir des caches _SLRU_.