El costo real de un índice extra en Postgres
· 7 min
Los índices suelen tratarse como un almuerzo gratis, "¿lento? agrega un índice", pero cada índice es una segunda estructura de datos que la base tiene que mantener, no solo un atajo de lectura.
Cada escritura en la tabla es una escritura más por índice
Un INSERT, UPDATE o DELETE sobre una columna indexada también tiene que actualizar el árbol B del índice correspondiente. Con N índices, el costo de escritura de esa columna se multiplica por N+1, aproximadamente, en tablas con mucha escritura, esto se acumula rápido y puede pesar más de lo que compensa la ganancia en lectura.
Espacio en disco que nadie mide hasta que duele
El espacio que ocupan los índices compuestos o sobre columnas anchas puede rivalizar con el tamaño de la propia tabla. Esto afecta la tasa de aciertos de la caché de páginas (shared_buffers), ya que más páginas en disco compiten por la misma caché, un efecto indirecto que ralentiza el resto del sistema sin que ninguna query en particular parezca culpable.
Más opciones para que el planner se equivoque
Más índices significan más planes de ejecución para que el planner considere, y estadísticas desactualizadas o datos con distribución sesgada pueden hacer que elija un índice peor de lo esperado. Más opciones no es estrictamente mejor si las estimaciones de costo detrás de la elección están equivocadas.
Cuándo el índice realmente compensa
Vale la pena revisar `pg_stat_user_indexes` para encontrar índices que nunca se usan, preferir un índice compuesto que cubra varios patrones de consulta en lugar de varios índices estrechos, y solo agregar un índice nuevo después de confirmar con `EXPLAIN ANALYZE` que la query en cuestión de verdad está haciendo un sequential scan que importa.