J'effectue les opérations suivantes :
- insertions de millions de lignes dans une table
- j'attends l'autovacuum
- insertion d'une ligne
- insertion d'une ligne
La dernière insertion d'une ligne génère XGo de WAL ! A quoi est-ce dû ?
Code : Tout sélectionner
select pg_current_wal_lsn();
create table d_mc6 (
metadata_id integer not null,
message_id bigint,
content_type integer,
content text,
is_encrypted boolean,
data_type character varying(255));
-- Insertion gros volume de messages
Insert Into d_mc6 values (1234, 14536, 1, 'Ce message est un message de test pas tres long', 'f', 'text');
Insert into d_mc6 select * from d_mc6; -- *xx jusqu a INSERT 0 16777216
SELECT pg_size_pretty(pg_current_wal_lsn() - '3D/5A000C68'::Pg_lsn);
-- Insertion petit volume de messages
Insert Into d_mc6 values (6666, 564654, 1, 'Ce message est un message de test en faible nombre', 'f', 'text');
Insert into d_mc6 select * from d_mc6 where message_id=564654; -- donc n'insere qu'une seule ligne
SELECT pg_size_pretty(pg_current_wal_lsn() - '3D/5A000C68'::Pg_lsn);
Ce cluster a les checksums activés.
Une utilisation de pg_waldump sur les fichiers WAL archivés dans Barman pendant cette période donne des lignes de ce type :
rmgr: XLOG len (rec/tot): 49/ 8173, tx: 0, lsn: 2F/DCFFC7F0, prev 2F/DCFFA7E8, desc: FPI_FOR_HINT , blkref #0: rel 1663/16387/33532 blk 158784 FPW
La clé du mystère est est "FPI_FOR_HINT" , voir par exemple https://www.postgresql.org/message-id/C ... .gmail.com
Ce n'est pas l'insert en lui-même qui génère les WAL mais le 1er SELECT effectué, le mécanisme "Hint Bits" est expliqué ici : https://wiki.postgresql.org/wiki/Hint_Bits
Conclusion : c'est à prendre en considération mais c'est documenté et attendu