Re: plan de ejecución

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.