El ORM no deja de ser una herramienta como cualquier otra...

"Si tienes un martillo, todo te parecen clavos"

El mar., 30 oct. 2018 21:07, Alvaro Herrera <alvhe...@2ndquadrant.com>
escribió:

> Diego escribió:
> > En estos días, a raíz de un tema con hibernate, implemente un
> log_statement
> > en all y empece a reportar consultas con 50 campos o mas (saltaron
> algunas
> > con 1200, y 50 joins)  y no es que postgres no lo soportaba, sino que
> > tardaba 90 segs en contestar. Estas consultas median entre 80 y 100 mil
> > caracteres porque en el select venian enumerados todos los campos (podría
> > haber sido un * y listo)
>
> Bueno, no es lo mismo un * que una lista de campos.  De hecho se
> recomienda NO usar * en consultas, porque puede resultar en sorpresas
> desagradables si más adelante llegas a cambiar el diseño de las tablas.
> Aunque si la consulta es escrita automáticamente por un ORM, lo más
> seguro es que liste todas las columnas.  Ahí el problema no es ni el ORM
> ni la base de datos, ni el problema tampoco es el rendimiento; el
> problema es que el ORM amplifica exponencialmente la estupidez (o
> debería decir más educadamente "ignorancia") de quien escribe la
> aplicación.
>
> No creo que el problema sea la longitud de la lista de campos a retornar
> (de hecho debe tener muy poco impacto), sino más bien la cantidad de
> tablas listadas en el FROM, porque el tiempo de optimización crece según
> el factorial de ese número (ver: from_collapse_limit,
> join_collapse_limit) ... pero el optimizador genético se hará cargo de
> encontrar un plan de ejecución no-tan-malo en tiempo no-tan-largo cuando
> la cantidad de tablas excede límites razonables.
>
> > Entonces, ya yendo para el lado de postgres, ¿que tanto impacto tengo que
> > esperar por una consulta de este tamaño?
>
> Si no está roto, no es necesario arreglarlo ;-)
>
> Deberías empezar por mandar a un curso de SQL a quien haya escrito esa
> parte de la aplicación.
>
> Saludos
>
> --
> Álvaro Herrera                https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
>

Reply via email to