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
