Constats expérimentaux
Des mesures réalisées sur des disques SATA rotatifs montrent un random_page_cost estimé à environ 125, soit 2 à 4 fois plus élevé que les valeurs observées sur des SSD. Cette différence contraste fortement avec la valeur par défaut de 4.0, qui était historiquement calquée sur des supports de stockage des années 2000 (PATA ou SCSI). L’écart indique que le paramètre par défaut ne représente plus le coût brut d’une lecture aléatoire sur les supports modernes.
Les retours d’utilisateurs qui ont augmenté random_page_cost constatent souvent une dégradation des performances, ce qui semble paradoxal si le paramètre devait simplement affiner le modèle de coût. L’explication réside dans le rôle compensatoire du paramètre vis‑à‑vis des lacunes du modèle de coût.
Modèle de coût et omissions majeures
Le calcul de coût de PostgreSQL se base principalement sur le temps CPU et le nombre d’opérations d’I/O. La mémoire n’est pas prise en compte comme ressource explicite, hormis la limite work_mem qui ne reflète que la taille maximale des tampons de travail. Ainsi, un plan qui nécessite de scanner 100 Go de données peut évacuer une quantité équivalente de pages du cache partagé, alors que le modèle ne mesure que le CPU et les accès disque.
De plus, le modèle ignore les effets de localisation. Un index peut ne toucher que 1 % d’une table de 100 Go, réduisant drastiquement la pression sur le cache, même si les accès sont aléatoires et plus lents en temps brut. En revanche, un scan séquentiel touche l’ensemble du fichier, augmentant l’ensemble actif en mémoire et risquant d’expulser d’autres données utiles.
Conséquences sur le planificateur
Le planificateur traite chaque requête comme si le système était à froid, sans tenir compte du jeu actif – la partie de la base réellement résidente en RAM. Il ne modélise pas non plus la concurrence entre plusieurs backends qui partagent la bande passante du disque. Dans un environnement à forte parallélisation, de nombreux scans séquentiels peuvent saturer le sous‑système de stockage, alors que le modèle suppose une bande passante infinie.
Ces omissions font que random_page_cost agit comme un proxy pour plusieurs phénomènes non modélisés : pression mémoire, effets de cache, et contention I/O. Diminuer la valeur pousse le planificateur à privilégier des plans plus localisés (index scans), limitant ainsi l’ensemble actif et réduisant la concurrence sur le disque.
Stratégies de réglage
Il n’existe pas d’outil automatisé capable de déterminer une valeur « idéale » à partir de mesures de latence séquentielle vs aléatoire, car le paramètre ne représente plus uniquement le coût I/O brut. Le réglage doit être spécifique au système et guidé par une surveillance continue. Une méthode consiste à analyser les requêtes les plus fréquentes via pg_stat_statements, identifier celles qui bénéficieraient d’un accès plus localisé, ajuster random_page_cost en conséquence, puis mesurer l’impact sur le temps d’exécution et sur les autres requêtes.
En pratique, les environnements dominés par des SSD voient souvent des valeurs proches de 1.0 à 2.0, tandis que les charges lourdes en scans séquentiels sur des disques rotatifs peuvent justifier des valeurs supérieures à 4.0. Le réglage reste un compromis entre précision du modèle et stabilité globale du système.
