Re: Rendimiento de funciones

On Fri, Mar 18, 2005 at 03:59:37PM -0500, Juan Pablo Espino wrote:
> Cierto definitivamente hay que saber preguntar.

grmph ...

> On Fri, 18 Mar 2005 16:30:37 -0400, Alvaro Herrera
> <alvherre(at)dcc(dot)uchile(dot)cl> wrote:
> > On Fri, Mar 18, 2005 at 01:03:47PM -0500, Juan Pablo Espino wrote:
> >
> > > On Fri, 18 Mar 2005 13:50:29 -0400, Alvaro Herrera
> > > <alvherre(at)dcc(dot)uchile(dot)cl> wrote:
> >
> > > > Usan distinta infraestructura, asi que en realidad depende de lo que
> > > > estes haciendo. Con plpgsql se guarda el parse tree y los planes de
> > > > ejecucion de las consultas, a menos que uses EXECUTE. Por lo tanto si
> > > > usas esto ultimo muy a menudo, el rendimiento tiende a bajar.
>
> Por qué el rendimiento tiende a bajar?, si uso EXECUTE dentro de una
> función en plpgsql entonces no se guardaría el parse tree y los planes
> de ejecución?

Precisamente. Lo que hace EXECUTE es evitar que eso suceda (se guarda
la consulta como string y se construye el plan en tiempo de ejecucion de
la funcion); a diferencia del resto de la funcion cuyo plan se construye
en tiempo de compilacion.

> > > > Por otro lado algunas funciones SQL se procesan "inline" en las
> > > > consultas, por lo tanto el plan de ejecucion las considera como si fueran
> > > > parte de la consulta y no como objetos opacos (que es lo que sucede con
> > > > plpgsql y el resto de las funciones)
>
> que son objetos opacos?, mil gracias, saludos

Opacos == el optimizador no los examina internamente para saber como
manejarlos.

Si creas una SRF, por ej., haces una consulta compleja en torno a
ella, y miras el EXPLAIN, puedes notar que el optimizador siempre cree
que la funcion retornara 1000 filas. No tiene modo de saber mejor.
Esto en contraste con la estimacion que se hace del tamaño de los
resultados en consultas "optimizables" ...

http://developer.postgresql.org/docs/postgres/planner-stats-details.html

De SRFs, el optimizador no tiene ninguna estadistica y tiene que
adivinar.

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"La primera ley de las demostraciones en vivo es: no trate de usar el sistema.
Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen)