分析為什么只使用first_value的寫法，且為了完全使用first_value不惜二次sort,原因如下：

WINDOW CALL: WINDOW window_name (partition by xxx order by xxx)
在使用first_value,last_value的時候，partition和order by會對得出的結(jié)果有影響。
分析函數(shù)包含三個分析子句：partition by,order by ,window.window里面rows的方式如下：unbounded preceding(第一行）,current row（當前行）,unbounded following（最后一行）
（1）語句為(partition by xxx order by xxx)，則默認的窗口為 unbounded preceding and current row
（2）語句為(partition by xxx), 窗口默認為unbounded preceding and unbounded following
（3）語句為()，窗口默認為全體結(jié)果集。
可能出現(xiàn)的問題就是語句使用第一種方式的時候。
測試環(huán)境如下：
create table windowcheck
(
?oc_date? integer ,
city???? varchar(50),
id?????? integer,
sale???? integer
);
select *from windowcheck;
?oc_date? | city |? id? | sale ?
----------+------+------+-------
20120701 | bj?? | 3299 | 10040
20120701 | cs?? | 3210 |? 7100
20120701 | nj?? | 3300 |? 8900
20120701 | nj?? | 3301 |? 9000
20120701 | tj?? | 3303 |? 3890
20120701 | wh?? | 3302 |? 4700
select oc_date,city,id,sale,last_value(sale) over (partition by oc_date order by city) last_value
from windowcheck;
?oc_date? | city |? id? | sale? | last_value
----------+------+------+-------+------------
20120701 | bj?? | 3299 | 10040 |????? 10040
20120701 | cs?? | 3210 |? 7100 |?????? 7100
20120701 | nj?? | 3301 |? 9000 |?????? 8900
20120701 | nj?? | 3300 |? 8900 |?????? 8900
20120701 | tj?? | 3303 |? 3890 |?????? 3890
20120701 | wh?? | 3302 |? 4700 |?????? 4700
問題出來了：我們通過oc_date進行分區(qū)，對city進行排序，得出的結(jié)果集最后一個值為wh,其sale值為4700.那我們原來的想法就是結(jié)果集所有的last_value應該都為4700。那么問題出在哪個地方呢？問題出在之前寫的窗口的范圍上了。有partition與order的默認的窗口為 unbounded preceding and current row。此時，讀取第一條的時候，窗口范圍僅自己一條，其last_value值為10040，讀取第二條的時候，窗口范圍為第一條與自己這一條，那么得出last_value值 為7100,以此類推.解決方案就是把窗口范圍擴大些。語句如下：
select oc_date,city,id,sale,last_value(sale) over (partition by oc_date order by city rows between unbounded preceding and unbounded following) last_value
from windowcheck;
到這里，把窗口范圍大小會引起的歧義解決了。還有一個疑惑是：如果在使用分區(qū)函數(shù)的時候，這個SQL語句本身也進行排序會怎么樣？因為SQL語句的結(jié)果集的順序會影響ast_value或者first_value的值。這里就要分析整個語句的先后執(zhí)行順序了：分析函數(shù)是在整個SQL查詢結(jié)束后(SQL語句中的ORDER BY的執(zhí)行比較特殊)再進行的操作, 也就是說
SQL語句中的ORDER BY也會影響分析函數(shù)的執(zhí)行結(jié)果。分析語句如下：
--產(chǎn)生結(jié)果集的SQL語句的order by與分區(qū)函數(shù)里面的order by是一致的
select oc_date,city,id,sale,last_value(sale) over (partition by oc_date order by city rows between unbounded preceding and unbounded following) last_value
from windowcheck order by city;
?oc_date? | city |? id? | sale? | last_value
----------+------+------+-------+------------
20120701 | bj?? | 3299 | 10040 |?????? 4700
20120701 | cs?? | 3210 |? 7100 |?????? 4700
20120701 | nj?? | 3301 |? 9000 |?????? 4700
20120701 | nj?? | 3300 |? 8900 |?????? 4700
20120701 | tj?? | 3303 |? 3890 |?????? 4700
20120701 | wh?? | 3302 |? 4700 |?????? 4700
--產(chǎn)生結(jié)果集的SQL語句的order by與分區(qū)函數(shù)里面的order by不一致
select oc_date,city,id,sale,last_value(sale) over (partition by oc_date order by city rows between unbounded preceding and unbounded following) last_value
from windowcheck order by city desc;
?oc_date? | city |? id? | sale? | last_value
----------+------+------+-------+------------
20120701 | wh?? | 3302 |? 4700 |?????? 4700
20120701 | tj?? | 3303 |? 3890 |?????? 4700
20120701 | nj?? | 3301 |? 9000 |?????? 4700
20120701 | nj?? | 3300 |? 8900 |?????? 4700
20120701 | cs?? | 3210 |? 7100 |?????? 4700
20120701 | bj?? | 3299 | 10040 |?????? 4700
由以上二個語句，可以分析出：產(chǎn)生結(jié)果集的SQL語句里面的order by不會對分區(qū)函數(shù)里面的結(jié)果造成影響，原因是如果結(jié)果集的order by與分區(qū)函數(shù)里面的不一致時，先使用分區(qū)函數(shù)里面的order by進行結(jié)果運算，然后再執(zhí)行結(jié)果集里面的order by.如果一致，則分區(qū)函數(shù)分析時不需要排序。
GP里面使用WINDOW的另外方式
select oc_date,city,id,sale,last_value(sale) over (w) last_value
from windowcheck
where oc_date=20120701
WINDOW w as? (partition by oc_date order by city rows between unbounded preceding and unbounded following);

greenplum窗口函數(shù)使用淺析