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

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网站 | 国产日韩欧美精品一区 | 欧美乱人免费视频观看 | 日本欧美一二三区色视频 | 国产美女精品视频 | 欧美毛片xxxx | 五月天婷婷久久 | 在线观看一级 | 国内久久久久高清影视 | 欧美一级日本一级韩国一级 | 第一序列番外篇在哪里看 | 久久图库99图库 | 亚洲国产成人精品久久 | 99热这里只有精品6免费 | 欧洲自拍偷拍 | 欧美一级α片毛片免费观看 | 四虎精品永久在线 | 国产国产成人人免费影院 | 国产精品一区二区久久精品涩爱 | 亚洲国产模特在线播放 | 久久成人在线观看 | 2020国产精品永久在线观看 | 欧美精品香蕉在线观看网 | 国产成人影院一区二区 | 国产香蕉在线视频一级毛片 |