From: | "Jose R(dot) Prieto" <joser(dot)prieto(at)gmail(dot)com> |
---|---|
To: | pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: Tamaño de Query |
Date: | 2018-10-30 20:12:00 |
Message-ID: | CAPZ_=WSc4AviBV4n+jM9+m_5TAF7X5MRZ81syqMM2bUAgnBCpQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
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 <alvherre(at)2ndquadrant(dot)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
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Hellmuth Vargas | 2018-10-31 13:48:43 | Re: Ayuda con armar saldos |
Previous Message | Alvaro Herrera | 2018-10-30 20:07:20 | Re: Tamaño de Query |