El parámetro random_page_cost de PostgreSQL, cuyo valor por defecto es 4.0, nunca fue una medición cruda del coste de la E/S aleatoria frente a la secuencial: nuevos experimentos del autor con discos rotacionales SATA arrojan estimaciones de ~125, entre 2 y 4 veces superiores a las obtenidas con SSD. ¿Por qué, entonces, subir el valor no mejora el rendimiento e incluso lo empeora? La respuesta está en las lagunas del modelo de costes del planificador: ignora la memoria y la localidad de acceso. El planificador no contabiliza cuánta memoria emplea realmente un plan ni entiende el concepto de conjunto activo, es decir, el subconjunto de la base de datos realmente consultado. Un escaneo secuencial sobre una tabla de 100 GB puede expulsar de caché casi todos los datos, mientras que un índice suele acceder solo a la fracción relevante, manteniendo el conjunto activo bajo control. Con varios backends ejecutando escaneos secuenciales en paralelo, además, se agota el ancho de banda de almacenamiento. En este contexto, random_page_cost actúa como un proxy para empujar al planificador hacia planes más localizados y eficientes en caché. No existe, por tanto, una herramienta que calcule el valor “correcto” del parámetro tras perfilar el almacenamiento: el ajuste debe ser específico de cada sistema, guiado por la monitorización de pg_stat_statements y por la observación del impacto en las consultas principales.
Noticias agregadas con IA