Guillermo E. Villanueva escribió: > Muchas gracias Alvaro, tremendo crack ud. > Luego de ejecutar (en un ambiente de testing) > > ALTER TABLE companies ALTER id SET STATISTICS 10000; > > ALTER TABLE companies ALTER fulldate SET STATISTICS 10000; > > ANALYZE companies; > El explain de la query en cuestión cambió totalmente > Ahora si utiliza primero el índice de la clave primaria y luego recien > filtra por fechas > > Si me puedes remitir a algun material para leer al respecto y entender > porque pasaba esto y por que se solucionó te lo agradeceré!
Esta charla de Divya Sharma explica lo de las estadísticas, https://www.postgresql.eu/events/pgconfde2024/schedule/session/5369-understanding-postgresql-statistics-to-optimize-performance/ lamentablemente me parece que no hay grabación de la misma. Vuelvo a insistir que el número 10000 probablemente es mucho más alto de lo que realmente necesitas, y causa que el optimizador demore más de lo necesario. Recomendaría probar con otros valores (200, 500) hasta encontrar un punto intermedio razonable. > Aunque no necesité la otra solución que comentabas, si me gustaría > saberla, La charla de Divya Sharma explica esto también, aunque debe haber alguna de Tomas Vondra ... ah sí, esta: https://www.youtube.com/watch?v=xPorz6N8ogE No conozco recursos en castellano. > intenté algunas cosas con subqueries pero no mejoraba, Normalmente el optimizador "aplana" (flatten) las subconsultas, que esencialmente significa que las elimina y lo vuelve a la misma estructura que si no tuvieras la subconsulta, por eso no ves ninguna mejora. Pero si a la subconsulta le agregas OFFSET 0, entonces se convierte en una "barrera de optimización", evitando que haga ese aplanamiento, y entonces sí podrías ver que el plan cambia. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ Syntax error: function hell() needs an argument. Please choose what hell you want to involve.
