🚀 go-pugleaf

On Tue, 28 Nov 2017 08:15:33 +0100, Andrzej Stróżyński wrote:

> W dniu 2017-11-27 o 22:17, Roman Tyczka pisze:
>> On Mon, 27 Nov 2017 22:10:32 +0100, Andrzej Stróżyński wrote:
>> 
>>>>>> SELECT A, B, C,
>>>>>>     SUM(C) OVER (),
>>>>>>     SUM(C) OVER (ORDER BY A, B),
>>>>>>     SUM(C) OVER (PARTITION BY A),
>>>>>>     SUM(C) OVER (PARTITION BY A ORDER BY B)
>>>>>>     FROM TEST
>>>>>>
>>>>>> i wyniki:
>>>>>>
>>>>>> A|  B|   C|  SUM| SUM_1| SUM_2| SUM_3|
>>>>>> -------------------------------------
>>>>>> 1|  1|  30|  141|    30|    60|    30|
>>>>>> 1|  2|  20|  141|    50|    60|    50|
>>>>>> 1|  3|  10|  141|    60|    60|    60|
>>>>>> 2|  1|  25|  141|    85|    40|    25|
>>>>>> 2|  2|  15|  141|   100|    40|    40|
>>>>>> 3|  1|  41|  141|   141|    41|    41|
>>>>>>
>>>>>
>>>>> Wnioskuję wyłącznie z obserwacji Twojego wyniku:
>>>>> ORDER BY powoduje sumowanie narastająco.
>>>>> SUM_3 jest partycjonowane więc licznik zeruje się przy zmianie wartości
>>>>> partycjonującej.
>>>>
>>>> czyli ORDER BY odcina z sumy wiersze, to dość nieoczywiste dla mnie i
>>>> trochę nieintuicyjne
>>>
>>> Odcina PARTITION BY.
>>> ORDER BY decyduje o kolejności sumowania wewnątrz partycji.
>>   
>> Ale czekaj... kolumna SUM_1 pochodzi z SUM(C) OVER (ORDER BY A, B) a tu nie
>> ma PARTITION. Co zatem ucina sumę do raptem jednego wiersza z wartością 30?
> 
> No właśnie nic tu nie ucina (nie zeruje) wyniku w trakcie sumowania.
> Zaczyna od 0 i sumuje narastająco kolejne wiersze wg zadanej kolejności.

Ok, to ma sens, ale w takim razie gdy zrobiłem jak prosiłeś order by C i
wyszło:

10
30
60
15
40
41

to jak to powstało?
kolumna C posortowana wygląda tak:

10
15
20
25
30
41

zatem narastająca suma powinna wyjść:

10
25
45
70
100
141

czyli inaczej, skąd ta różnica?

-- 
pozdrawiam
Roman Tyczka