Re: Duda sobre OVER PARTITION

Excerpts from mvillagomez's message of mié sep 15 12:14:21 -0400 2010:

> Estos resultados son los que busco pero quize ordenar por el sueldo; así
> que modifique la consulta de la siguiente manera:
> SELECT nombre, puesto, sueldo, avg(sueldo) OVER(PARTITION BY puesto ORDER
> BY puesto, sueldo)
> FROM cat_empleado
>
> Y obtuve los siguientes resultados:
>
>
>
> El grupo (o partición) de "Desarrolladores" me parece esta siendo
> calculado incorrectamente por que, el empleado "Darien"
> tiene su sueldo neto, el empleado "John" tiene el promedio de su sueldo
> junto con el de "Darien" y el empleado "Miguel" tiene el
> promedio del grupo de desarrolladores.
> Quiero preguntar si esto es correcto y de ser así por qué?

Si no entiendo mal, es correcto, porque el "frame" sobre el cual se
están calculando los avg() es RANGE UNBOUNDED PRECEDING. Creo que lo
que tú quieres es que el frame sea RANGE BETWEEN UNBOUNDED PRECEDING AND
UNBOUNDED FOLLOWING.

Ten presente la siguiente nota en 9.19, "Window Functions":

When an aggregate function is used as a window function, it
aggregates over the rows within the current row's window frame.
To obtain aggregation over the whole partition, omit ORDER BY or
use ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING. An
aggregate used with ORDER BY and the default window frame
definition produces a "running sum" type of behavior, which may
or may not be what's wanted.
http://www.postgresql.org/docs/8.4/static/functions-window.html

Esta información completementa a lo que se encuentra en 4.2.8. "Window
Function Calls":

The frame_clause specifies the set of rows constituting the
window frame, for those window functions that act on the frame
instead of the whole partition. The default framing option is
RANGE UNBOUNDED PRECEDING, which is the same as RANGE BETWEEN
UNBOUNDED PRECEDING AND CURRENT ROW; it selects rows up through
the current row's last peer in the ORDER BY ordering (which
means all rows if there is no ORDER BY).
http://www.postgresql.org/docs/8.4/static/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS

Lo que no me queda totalmente claro es por qué no se presentó este mismo
problema en la primera consulta que muestras. Quizás se debe a que la
cláusula PARTITION es idéntica al ORDER BY.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support