亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

greenplum窗口函數使用淺析

系統 2029 0
?最近處于系統不活躍期,沒怎么升級,因此有了時間可以對整個ETL系統在穩定的基礎上進行優化。每天列出TOP 10 COST TIME JOB進行分析,其中TOP1 COSTTIME JOB采用了窗口函數first_value和last_value,結果SQL全部使用的是first_value,并且為了全部使用first_value,對窗口函數進行了二次排序。通過explain這段代碼,可以發現兩次sort消耗的時候大概是一次sort的1.7倍,把sort二次改進成一次,并且把SQL從datastage遷移到greenplum的function里面,整個過程由24分鐘降至40秒。

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

WINDOW CALL: WINDOW window_name (partition by xxx order by xxx)
在使用first_value,last_value的時候,partition和order by會對得出的結果有影響。
分析函數包含三個分析子句: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)語句為(),窗口默認為全體結果集。
可能出現的問題就是語句使用第一種方式的時候。
測試環境如下:
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進行分區,對city進行排序,得出的結果集最后一個值為wh,其sale值為4700.那我們原來的想法就是結果集所有的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;
到這里,把窗口范圍大小會引起的歧義解決了。還有一個疑惑是:如果在使用分區函數的時候,這個SQL語句本身也進行排序會怎么樣?因為SQL語句的結果集的順序會影響ast_value或者first_value的值。這里就要分析整個語句的先后執行順序了:分析函數是在整個SQL查詢結束后(SQL語句中的ORDER BY的執行比較特殊)再進行的操作, 也就是說
SQL語句中的ORDER BY也會影響分析函數的執行結果。分析語句如下:
--產生結果集的SQL語句的order by與分區函數里面的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
--產生結果集的SQL語句的order by與分區函數里面的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
由以上二個語句,可以分析出:產生結果集的SQL語句里面的order by不會對分區函數里面的結果造成影響,原因是如果結果集的order by與分區函數里面的不一致時,先使用分區函數里面的order by進行結果運算,然后再執行結果集里面的order by.如果一致,則分區函數分析時不需要排序。
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窗口函數使用淺析


更多文章、技術交流、商務合作、聯系博主

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號聯系: 360901061

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。

【本文對您有幫助就好】

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會非常 感謝您的哦!!!

發表我的評論
最新評論 總共0條評論
主站蜘蛛池模板: 99在线影院 | 高清影院|精品秒播3 | 九九国产 | 精品 日韩 国产 欧美在线观看 | 毛片在线看网站 | 四虎永久免费观看紧急入口 | 日本大胆一区免费视频 | 精品国产日韩亚洲一区91 | 66av99精品福利视频在线 | 久青草国产免费观看 | 亚洲精品色综合久久久 | 99久久综合 | 国产h版大片在线播放 | 狠狠涩| 日本天天操 | 精品国产一区二区 | 酒色网站| 午夜大片免费男女爽爽影院久久 | 中文字幕在线激情日韩一区 | 99热这里只有精品第一页 | 曰本毛片va看到爽不卡 | 亚洲欧美日本国产综合在线 | 91精品久久一区二区三区 | 亚洲图区欧美 | 中文字幕在线不卡精品视频99 | 亚洲精品乱码久久久久久中文字幕 | 亚洲一二区视频 | 九色视频网站 | 2021久久精品永久免费 | 日本免费不卡视频 | 国产日产欧美精品一区二区三区 | 一级毛片一级毛片免费毛片 | 亚洲欧美中文字幕专区 | 毛片aaa| 亚洲第一视频在线播放 | 免费一区二区三区四区五区 | 日韩视频在线一区 | 伊人精品视频在线观看 | 日韩综合nv一区二区在线观看 | 亚洲欧洲精品视频在线观看 | 99这里只有精品视频 |