Administrace komentářů

Velmi pekna uloha!

Postgresql zial nevie efektivne pouzit index pre group by - pouzije index only scan iba ked sa mu zakaze seq. scan.

Najprv definica tabulky, a simulacia tvojich dat: (testovane na pg11)

--DROP TABLE IF EXISTS van;
CREATE TABLE van (
   rodatum timestamp
 , server  integer NOT NULL
 , vanview integer NOT NULL
);
-- populate with 10M of records with 25 distinct combinations of server & vanview
INSERT INTO van (server, vanview, rodatum)
   SELECT (random() * 4)::int
        , (random() * 4+5)::int
        , ts + ((random() * 5000)::int || 'seconds')::interval
      FROM generate_series('2000-01-01'::timestamp, now(), '1minute') AS x(ts)
;

SELECT count(*) FROM van;
-- 10095150
SELECT count(*) FROM van GROUP BY (server, vanview);
-- (25 rows)

Jednotlive stlpce vo viacstlpcovych indexoch je potrebne radit v poradi selektivity a znovupouzitelnosti. Ak query filtruje len podla niektorych stlpcov indexu zlava, vie ho pouzit. A preto sa pouzije index ix_van_server_vanview_rodatum na SELECT min(server), ale uz nie na SELECT min(vanview).

 -- used by min(server), max(rodatum) per server&vanview
CREATE INDEX ix_van_server_vanview_rodatum ON van (server, vanview, rodatum DESC NULLS LAST);
 -- used by min(vanview)
CREATE INDEX ix_van_vanview ON van (vanview);

Test tvojej query pre porovnanie casov:

EXPLAIN (BUFFERS, ANALYZE) select max(rodatum), server, vanview  FROM van GROUP BY server, vanview;
-- actual time=1791.880..1791.936
-- Parallel Seq Scan on van

Pouzil sa Seq scan, napriek tomu, ze existuje ix_van_server_vanview_rodatum, skusim ho zakazat:

SET enable_seqscan = OFF;
EXPLAIN (BUFFERS, ANALYZE) select max(rodatum), server, vanview  FROM van GROUP BY server, vanview;
-- actual time=218.738..3580.570
-- Parallel Index Only Scan using ix_van_server_vanview_rodatum

...este pomalsie - zda sa, ze planner funguje spravne

Kedze mame pomerne male mnozstvo kombinacii ((count(server)*count(vanview))==25), napadlo ma pouzit index ix_van_server_vanview_rodatum tak, ze mu podsuniem 25 roznych hodnot, co by bezalo so zlozitostou O(25 log 10^7). Takze potrebujem ziskat 25 unikatnych hodnot. Lenze SELECT DISTINCT je este pomalsi, nez SELECT server, vanview GROUP BY server, vanview:

SELECT DISTINCT server, vanview FROM van
-- Time: 1878,862 ms (00:01,879)
SELECT server, vanview FROM van GROUP BY server,vanview
-- Time: 980,318 ms

Korelovana subquery je potom obmedzena pomalostou DISTINCT/GROUP-BY:

SELECT max(rodatum), server, vanview
   FROM van
   WHERE (server,vanview) IN (SELECT DISTINCT server, vanview FROM van)
   GROUP BY server,vanview
;
-- Time: 5028,114 ms (00:05,028)

SELECT (
   SELECT max(v.rodatum)
      FROM van AS v
      WHERE (v.server, v.vanview) = (vv.server, vv.vanview)
   ), server, vanview
   FROM (SELECT server, vanview FROM van GROUP BY server,vanview) AS vv
   GROUP BY server, vanview
;
--Time: 984,181 ms

...je vidiet mierne zrychlenie, ale stale sme v radoch sekund.

A tu prichadza trik s rekurzivnou CTE pre indexovany DISTINCT v kombinacii s horeuvedenou korelovanou subquery:

--EXPLAIN (BUFFERS, ANALYZE) 
WITH RECURSIVE t AS (
   SELECT min(server) AS s FROM van
   UNION ALL
   SELECT (SELECT min(server) FROM van WHERE server > t.s)
   FROM t WHERE t.s IS NOT NULL
)
, tt AS (
   SELECT min(vanview) AS v FROM van
   UNION ALL
   SELECT (SELECT min(vanview) FROM van WHERE vanview > tt.v)
   FROM tt WHERE tt.v IS NOT NULL
)
SELECT (
   SELECT max(rodatum)
      FROM van
      WHERE server = s
        AND vanview = v
   ), s, v
   FROM t, tt
   WHERE s IS NOT NULL
     AND v IS NOT NULL
;
-- Time: 1,679 ms

Pre vysvetlenie vid https://wiki.postgresql.org/wiki/Loose_indexscan