Votre planificateur de requêtes croit-il encore à un disque mécanique ?
Dans PostgreSQL, deux paramètres de coût orientent presque tous les choix du planificateur entre un parcours séquentiel et un parcours d'index : seq_page_cost et random_page_cost. Leurs noms suggèrent qu'ils décrivent le temps de lecture d'une page sur disque. C'est une lecture trop littérale, et elle conduit à de mauvaises décisions de réglage. Cet article revient sur leur vraie définition, sur l'explication erronée du fameux « 4,0 » et sur la manière d'auditer ces valeurs selon votre stockage. Il s'appuie sur l'analyse publiée par Christophe Pettus : Christophe Pettus: All Your GUCs in a Row: random_page_cost and seq_page_cost.
Deux paramètres, une échelle de coût
seq_page_cost vaut 1,0 par défaut. Ce n'est pas une durée : c'est l'unité de mesure sur laquelle repose toute l'échelle de coût du planificateur. Les autres constantes s'y rapportent. Par exemple, cpu_tuple_cost vaut 0,01 parce que le traitement d'une ligne par le processeur est considéré comme équivalent à un centième de lecture séquentielle d'une page.
random_page_cost vaut 4,0 par défaut, et cette valeur est en place depuis que le paramètre existe, à l'époque de la version 7.0. Le paramètre seq_page_cost est plus récent : avant la version 8.2, la lecture séquentielle était une constante interne non modifiable.
Les deux sont de type flottant, avec un minimum de 0, et peuvent être modifiés au niveau de la session. Depuis la version 9.0, il est aussi possible de les surcharger par tablespace avec ALTER TABLESPACE ... SET. C'est le seul moyen de signaler au planificateur que deux types de stockage cohabitent dans un même cluster, par exemple du SSD et des disques plus lents.
Où chaque tarif s'applique
Le planificateur facture seq_page_cost pour chaque page lue lors d'un parcours séquentiel, auquel s'ajoute le coût processeur par ligne. L'auteur donne un exemple chiffré : une table de 34 483 pages contenant 1 999 998 lignes coûte exactement 34 483 + 1 999 998 × 0,01 = 54 482,98, et EXPLAIN affiche ce nombre à la décimale près. Le tarif random_page_cost, lui, est appliqué aux pages d'index que le parcours doit lire.
Le mythe du ratio 4 pour 1
L'explication courante veut que 4,0 corresponde à un disque mécanique où un accès aléatoire coûte environ quatre fois une lecture séquentielle. Selon l'article, c'est faux. Sur un disque rotatif, une lecture aléatoire revient plutôt à une quarantaine de lectures séquentielles. La documentation justifiait pourtant la valeur 4,0 par ce ratio de 40, atténué par un taux de succès de cache supposé de 90 %. Cette explication est restée en place pendant treize ans, jusqu'à son retrait en octobre 2025.
Autrement dit, random_page_cost n'a jamais été le coût d'une lecture aléatoire. C'est ce coût multiplié par la probabilité que la lecture atteigne réellement le disque. Une grande partie des erreurs de réglage vient de là : on lit le nom du paramètre au lieu de sa définition.
L'auteur signale aussi une correction à un article précédent sur les constantes cpu_index_tuple_cost, cpu_operator_cost et cpu_tuple_cost, qui reprenait l'explication populaire erronée du ratio 4 pour 1.
Ce que cela implique pour votre configuration
Puisque le paramètre intègre une hypothèse de cache, la bonne question à se poser n'est pas « mon disque est-il rapide ? » mais « quelle part de mes lectures d'index atteint réellement le disque ? ». Quelques pistes d'audit en découlent :
- Relisez la valeur effective de
random_page_cost sur vos instances, y compris les surcharges par tablespace, par base ou par rôle.
- Sur du SSD ou du NVMe, l'écart réel entre lecture aléatoire et séquentielle est faible : une valeur de 4,0 pousse alors le planificateur à préférer des parcours séquentiels qui ne sont pas toujours les meilleurs.
- Si votre jeu de données tient largement en mémoire, la probabilité d'atteindre le disque est basse, ce qui plaide aussi pour une valeur plus proche de
seq_page_cost.
- Utilisez les tablespaces avec des valeurs distinctes quand plusieurs types de stockage coexistent.
- Validez chaque changement avec
EXPLAIN (ANALYZE, BUFFERS) sur vos requêtes critiques, en comparant les plans avant et après, plutôt que de vous fier à une valeur recommandée trouvée en ligne.
Ces réglages se testent d'abord au niveau de la session, ce qui permet de mesurer l'effet sur une requête précise sans toucher à la configuration globale.
En résumé
Les paramètres seq_page_cost et random_page_cost ne décrivent pas des temps de disque : ils expriment des coûts relatifs, le second embarquant une hypothèse de cache. Abandonner l'idée du « disque mécanique quatre fois plus lent » permet de raisonner sur ce qui compte vraiment : votre stockage réel, la taille de vos données par rapport à la mémoire et les plans effectivement choisis. Lisez l'analyse complète de Christophe Pettus pour le détail des calculs, puis auditez vos instances.
