Re: Rendimiento de funciones

On Fri, Mar 18, 2005 at 01:08:39PM -0500, Leonardo Boet Sánchez wrote:

> Quisiera saber si el rendimiento de funciones con lenguaje tipo SQL es
> similar a las funciones en lenguaje plpgsql...

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 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)

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"La vida es para el que se aventura"

Hola

On Fri, 18 Mar 2005 13:50:29 -0400, Alvaro Herrera
<alvherre(at)dcc(dot)uchile(dot)cl> wrote:
> On Fri, Mar 18, 2005 at 01:08:39PM -0500, Leonardo Boet Sánchez wrote:
>
> > Quisiera saber si el rendimiento de funciones con lenguaje tipo SQL es
> > similar a las funciones en lenguaje plpgsql...
>
> 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 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)

No comprendo muy bien y me interesa esta parte, me podrías sugerir
alguna lectura?

gracias.

Buenas tardes...

Quisiera saber si el rendimiento de funciones con lenguaje tipo SQL es similar a las funciones en lenguaje plpgsql...

Gracias de antemano..

Boet

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 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)
>
> No comprendo muy bien y me interesa esta parte, me podrías sugerir
> alguna lectura?

Cual parte? Las funciones inline? No hay mucho que leer, a menos que
sea el codigo: src/backend/optimizer/util/clauses.c:inline_function()

/*
* inline_function: try to expand a function call inline
*
* If the function is a sufficiently simple SQL-language function
* (just "SELECT expression"), then we can inline it and avoid the rather
* high per-call overhead of SQL functions. Furthermore, this can expose
* opportunities for constant-folding within the function expression.
*
* We have to beware of some special cases however. A directly or
* indirectly recursive function would cause us to recurse forever,
* so we keep track of which functions we are already expanding and
* do not re-expand them. Also, if a parameter is used more than once
* in the SQL-function body, we require it not to contain any volatile
* functions (volatiles might deliver inconsistent answers) nor to be
* unreasonably expensive to evaluate. The expensiveness check not only
* prevents us from doing multiple evaluations of an expensive parameter
* at runtime, but is a safety value to limit growth of an expression due
* to repeated inlining.
*
* We must also beware of changing the volatility or strictness status of
* functions by inlining them.
*
* Returns a simplified expression if successful, or NULL if cannot
* simplify the function.
*/

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"There is evil in the world. There are dark, awful things. Occasionally, we get
a glimpse of them. But there are dark corners; horrors almost impossible to
imagine... even in our worst nightmares." (Van Helsing, Dracula A.D. 1972)

Cierto definitivamente hay que saber preguntar.

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?

> > > 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

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)