Odwoływanie się do bieżącego wiersza w klauzuli FILTER o funkcji okna

Question

W PostgreSQL 9.4 funkcje okna mają nową opcję FILTER do wyboru podzbioru ramki okna do przetwarzania. Dokumentacja wspomina o tym, ale nie dostarcza próbki. Wyszukiwanie online dostarcza niektórych próbek, w tym z 2ndQuadrant, ale wszystkie znalezione przykłady są dość trywialne i mają stałe wyrażenia. To, czego szukam, to wyrażenie filtru, które zawiera wartość bieżącego wiersza.

Załóżmy Mam tabeli z wieloma kolumnami, z których jeden jest date typu:

col1 | col2 |  dt 
------------------------ 
    1 | a | 2015-07-01 
    2 | b | 2015-07-03 
    3 | c | 2015-07-10 
    4 | d | 2015-07-11 
    5 | e | 2015-07-11 
    6 | f | 2015-07-13 
...

definicja okno do przetwarzania na date na całej tabeli jest trywialnie skonstruowanej: WINDOW win AS (ORDER BY dt)

Interesuje mnie wiedzieć, ile wierszy jest obecnych w, powiedzmy, 4 dni przed bieżącym wierszem (włącznie). Więc chcę wygenerować ten wynik:

col1 | col2 |  dt  | count 
-------------------------------- 
    1 | a | 2015-07-01 | 1 
    2 | b | 2015-07-03 | 2 
    3 | c | 2015-07-10 | 1 
    4 | d | 2015-07-11 | 3 
    5 | e | 2015-07-11 | 3 
    6 | f | 2015-07-13 | 4 
...

FILTER klauzula funkcji okna wydaje się oczywistym wyborem:

count(*) FILTER (WHERE current_row.dt - dt <= 4) OVER win

Ale jak mogę określić current_row.dt (dla braku lepszego składni)? Czy to możliwe?

Jeśli nie jest to możliwe, czy istnieją inne sposoby wybierania zakresów date w ramce okna? Specyfikacja ramek nie jest pomocna, ponieważ jest ona oparta na wierszach.

Nie interesują mnie alternatywne rozwiązania z wykorzystaniem pod-zapytań, musi to być oparte na przetwarzaniu okien.

Answer 1

Nie jesteś w rzeczywistości agregująca wierszy, więc nowa klauzula agregująca FILTER nie jest właściwym narzędziem. Funkcja okna jest bardziej podobna, problem pozostaje jednak: okno nie może zależeć od wartości bieżącego rzędu. Może on liczyć tylko określoną liczbę wierszy poprzedzających lub następujących z klauzulą ​​ROWS.

Aby to wykonać, łączna liczba dziennych i LEFT JOIN do pełnego zestawu dni w zakresie. Następnie można zastosować funkcję okna:

SELECT t.*, ct.ct_last4days 
FROM (
    SELECT *, sum(ct) OVER (ORDER BY dt ROWS 3 PRECEDING) AS ct_last4days 
    FROM (
     SELECT generate_series(min(dt), max(dt), interval '1 day')::date AS dt 
     FROM tbl t1 
    ) d 
    LEFT JOIN (SELECT dt, count(*) AS ct FROM tbl GROUP BY 1) t USING (dt) 
    ) ct 
JOIN tbl t USING (dt); 

pomijając ORDER BY dt w definicji ramki wdowa zwykle roboty, ponieważ zamówienie jest przeniesione z generate_series() w podzapytania. Ale nie ma żadnych gwarancji w standardzie SQL bez wyraźnego ORDER BY i może on łamać bardziej złożone zapytania.

SQL Fiddle.

pokrewne:

• Select finishes where athlete didn't finish first for the past 3 events
• PostgreSQL: running count of rows for a query 'by minute'
• PostgreSQL unnest() with element number

Answer 2

Nie sądzę, nie ma żadnych składni, które oznacza "bieżący wiersz" w wyrażeniu . Plik gram.y dla postgrera sprawia, że ​​klauzula filtru przyjmuje tylko a_expr, która jest po prostu normalną klauzulą ​​wyrażenia. Tam nie jest niczym szczególnym dla funkcji okna lub klauzul filtru w wyrażeniu. O ile mogę znaleźć, jedynym bieżącym pojęciem wiersza w klauzuli window jest określenie granic ramki okna. Nie sądzę, że to ci pomoże , czego chcesz.

Jest możliwe, że można dostać jakąś trakcję z otaczającej zapytania:

http://www.postgresql.org/docs/current/static/sql-expressions.html

Kiedy pojawi się łączna ekspresja w podkwerendzie (patrz punkt 4.2.11 oraz sekcja 9.22), łączna jest zwykle oceniany w wierszach podzapytania. Ale wyjątek występuje, jeśli argumenty agregatu (i filter_clause, jeśli istnieją) zawierają tylko zmienne z zewnętrznego poziomu: agregacja należy wtedy do najbliższego takiego zewnętrznego poziomu, i jest obliczana na podstawie wierszy tego zapytania.

ale nie jest to dla mnie oczywiste.