Adrien nayrat

Just to give some context. Temporary tables are only visible in the session which created them. Thus, autovacuum can't see them. So, without running manual ANALYZE on temporary tables, Postgres...

Each time a new Postgres version is released, a new version is installed. Thus, we have 3 instances running on osmose1.davintech.ca but only one is used.

A quoi servirons les SSD SATA? J'ai peur que les performances ne soient vraiment pas bonnes si ce ne sont pas des SSD datacenter.

Ah, et on pourrait utiliser quelques Go du NVme comme SLOG pour absorber les pics en écriture

https://www.kingston.com/datasheets/SEDC500M_us.pdf Les DC500M ont une super endurance.

Si vous êtes passé en buster en utilisant pg_upgrade il faut reconstruire tous les index. La raison du pourquoi : https://postgresql.verite.pro/blog/2018/08/27/glibc-upgrade.html

> C'est plutôt pg_upgradecluster qui est utilisé. C'est pareil, enfin pg_upgradecluster c'est un wrapper debian autour de pg_upgrade.

Attention au modèle de SSD, même des NVMe peuvent avoir des perfs en écriture digne de disques mécaniques : - https://www.sebastien-han.fr/blog/2014/10/10/ceph-how-to-test-if-your-ssd-is-suitable-as-a-journal-device/ - https://yourcmc.ru/wiki/Ceph_performance - https://docs.google.com/spreadsheets/d/1E9-eXjzsKboiCCX-0u0r5fAjjufLKayaut_FOPxYZjc/edit#gid=0

Thanks for your answer. We can use pg_receivewal with pgbackrest ? Maybe I missed it ? My use case is very simple : "We want backup with RPO=0".

Hum, I don't see how I can do that with pg_receivewal : archive wal are in separate folder. Files are renamed and compressed with checksum : ``` ls /srv/backup/pgbackrest/archive/pg16/16-1/000000010000006C |tail...