Optimizando PostgreSQL para búsquedas eficientes - Capítulo 15

Pensé que PostgreSQL usaría los índices automáticamente… pero no.

En este post te cuento cómo optimicé las búsquedas y eliminé los escaneos secuenciales que estaban ralentizando todo. 🚀🔥

¿Por qué mi base de datos iba tan lenta?

Cuando implementé las búsquedas en PostgreSQL para mi SaaS, esperaba que fueran rápidas.

Después de todo, había creado índices y optimizado las consultas.

Pero...

Siempre hay un "pero"

No estaba obteniedo el rendimiento que yo quería.

Ya que, te lo voy a confesar, el rendimiento es y ha sido uno de mis grandes miedos.

En la base de datos si todo va bien espero tener miles y miles de registros y el rendimiento para mí es clave porque:

1. Afecta a la experiencia de usuario
2. Afecta a negocio

📅 Diario de un SaaS: Optimizando PostgreSQL para búsquedas eficientes

El problema apareció cuando me di cuenta de que, en vez de usar los índices creados, PostgreSQL decidía hacer escaneos secuenciales.

En pocas palabras, en vez de buscar de forma inteligente, leía toda la base de datos para encontrar un solo resultado.

Algo que no podía permitir porque no es nada escalable.

En resumen:

Esto no solo ralentizaba las búsquedas, sino que afectaba la escalabilidad del sistema.

Así que ahí estaba yo, preguntándome...

¿Por qué demonios PostgreSQL se negaba a usar los índices?

 

🔍 Problema detectado: PostgreSQL ignorando índices

Lo primero fue analizar qué estaba pasando.

Gracias a pg_stat_statements, descubrí que las consultas a parts y brands no estaban utilizando los índices correctamente.

¿Y qué significa eso en la vida real?

Que mi base de datos estaba haciendo el trabajo más duro de lo necesario.

Qué es el Stat Statement

Antes de entrar en detalle, hablemos de pg_stat_statements.

¿Qué es esto y por qué es tan importante? 🤔

Imagínate que tienes una cafetería y cada cliente pide café de una forma diferente: unos dicen 'un espresso', otros 'un café solo', y otros 'un corto'.

Si no llevas un registro de qué pedidos son los más comunes, cada vez que un cliente pida algo, el barista tendrá que pensar desde cero cómo hacerlo.

Por eso el pg_stat_statements es como el sistema de pedidos de un barista eficiente: guarda un historial de todas las consultas ejecutadas en PostgreSQL y te dice cuáles se repiten, cuáles son más lentas y cuáles podrías mejorar.

En otras palabras, pg_stat_statements es la memoria de PostgreSQL.

Nos permite ver qué consultas están funcionando mal, detectar patrones y optimizar el rendimiento en base a datos reales.

Sin él, sería como intentar mejorar el servicio de una cafetería sin saber qué café se vende más.

Así que cuando vi que mis consultas eran lentas, recurrí a pg_stat_statements para descubrir qué estaba pasando.

🛑 Aquí los principales problemas:

1. Escaneo secuencial en parts y brands. PostgreSQL estaba recorriendo toda la tabla en vez de usar los índices creados.
2. Índice en brands.name ignorado. A pesar de tener un índice en brands.name, PostgreSQL lo ignoraba y realizaba búsquedas lentas.
3. Consultas lentas detectadas en pg_stat_statements. Las búsquedas de piezas por marca eran ineficientes, afectando la escalabilidad.

Ver esto fue como descubrir que había construido una autopista y que todos los coches seguían usando el camino de tierra.

¡Pero para qué puse los índices, entonces!

Problemas al instalar Stat Statements:

Ojo, no te he dicho que todo esto me llevó guerra porque no podía instalar Stat Statements.

Tuve que hacer las mil y una (para variar)...

Pero lo conseguí!

🛠️ La solución: haciendo que PostgreSQL respete los índices

Después de varios intentos y pruebas, implementé estas soluciones para optimizar las búsquedas:

✅ Creación de índices en las columnas clave

• idx_parts_brand_id para acelerar la búsqueda de piezas por marca.
• idx_brands_name_text para forzar el uso del índice en brands.name.

✅ Análisis con EXPLAIN ANALYZE y pg_stat_statements

• Usé EXPLAIN ANALYZE para ver cómo PostgreSQL ejecutaba las consultas y confirmar si usaba los índices.
• Ajusté configuraciones para reducir escaneos secuenciales innecesarios.

✅ Forzar el uso del índice en brands.name

• Convertí el tipo de dato en la consulta con b.name::TEXT.
• Usé SET enable_seqscan = OFF para evitar que PostgreSQL hiciera escaneos secuenciales.

Finalmente, después de aplicar estos cambios, las consultas comenzaron a responder de manera mucho más eficiente.

📊 Resultados y beneficios

🔥 Las consultas ahora son rápidas como un rayo.

Pasamos de tiempos de ejecución de segundos a 0.043 milisegundos.

🔥 Se eliminaron los escaneos secuenciales.

PostgreSQL dejó de perder el tiempo recorriendo toda la tabla.

🔥 Confirmamos en pg_stat_user_indexes que PostgreSQL finalmente usa los índices como debe ser.

Pasar de consultas que tardaban siglos a milisegundos hizo una gran diferencia en el rendimiento del SaaS.

Fue un alivio ver que PostgreSQL por fin hacía lo que se suponía que debía hacer desde el principio.

💡 Lo que aprendí en el proceso

🔹 Crear índices no es suficiente. Hay que asegurarse de que PostgreSQL realmente los utilice.

🔹 Las herramientas de análisis como EXPLAIN ANALYZE y pg_stat_statements son indispensables. Si no analizas las consultas, es como estar programando a ciegas.

🔹 No hay que asumir que PostgreSQL tomará siempre la mejor decisión. A veces es necesario forzar el uso de los índices.

🔹 Optimizar una base de datos requiere ajustes constantes. Lo que funciona hoy puede no ser la mejor opción en el futuro, sobre todo cuando los datos crecen.

 

🚀 Próximos pasos

 

➡️ ¿Alguna vez PostgreSQL te ha ignorado los índices? Cuéntame cómo lo solucionaste.

Si quieres conocer otros artículos parecidos a Optimizando PostgreSQL para búsquedas eficientes - Capítulo 15 puedes visitar la categoría Proyecto-IA.