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

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條評論
主站蜘蛛池模板: 亚洲swag精品自拍一区 | 国产欧美另类久久精品91 | 成人精品一区久久久久 | 中文字字幕在线 | 日韩欧美印度一级毛片 | 欧美日韩在线播放 | 成人免费精品视频 | 亚洲黄a| 国产精品久久国产三级国电话系列 | 一个色亚洲 | 99热这里只有精 | 亚洲精品久久久久久久777 | 精品久久伦理中文字幕 | 理论片我不卡在线观看 | 人人爱天天做夜夜爽88 | 日本亚洲一区二区 | 国产日韩欧美91 | 日韩欧美毛片免费看播放 | 国产日韩欧美综合 | 成人午夜久久精品 | 亚洲三级中文字幕 | 久久久青青 | 中国一级毛片欧美一级毛片 | 免费一级毛片麻豆精品 | 美女一级大黄录像一片 | 99精品视频在线观看免费播放 | 久久久久久久一线毛片 | jizz中国视频 | yellow中文字幕久久网 | 九九精品国产兔费观看久久 | 亚洲欧美日韩国产精品影院 | 四虎国产精品成人永久免费影视 | 99视频精品全部国产盗摄视频 | 国产精品自线在线播放 | 色中色综合 | 婷婷国产成人久久精品激情 | 国产成人久久 | 狠狠狠色丁香婷婷综合久久五月 | 91在线看片 | 久久久这里只有精品免费 | 91精品国产综合久久婷婷 |