widok zmaterializowany to droga do tego, co nakreśliłeś. Wysyłanie zapytań dotyczących danych tylko do odczytu z ostatnich miesięcy działa bez ich odświeżania. Jeśli chcesz to również pokryć, możesz zaznaczyć specjalny przypadek w bieżącym miesiącu.
Podstawowe zapytanie może nadal korzystać z indeksu, a istnieją dwa kierunki, które możesz obrać:
Po pierwsze, częściowe indeksy tak jak teraz, nie kupisz wiele w swoim scenariuszu, nie warto. Jeśli zbierasz dane o wiele więcej miesięcy i najczęściej wysyłasz zapytania według miesiąca (i dodajesz/upuszczasz wiersze według miesiąca), partycjonowanie tabeli może być pomysłem, wtedy masz również automatycznie partycjonowane indeksy. Rozważę jednak Postgres 11 lub nawet nadchodzący Postgres 12.)
Jeśli Twoje wiersze są szerokie , utwórz indeks, który umożliwia skanowanie tylko do indeksu . Na przykład:
CREATE INDEX reportimpression_covering_idx ON reportimpression(datelocal, views, gender);
Powiązane:
Lub INCLUDE dodatkowe kolumny w Postgresie 11 lub nowszym:
CREATE INDEX reportimpression_covering_idx ON reportimpression(datelocal) INCLUDE (views, gender);
Inne , jeśli twoje wiersze są fizycznie posortowane według datelocal , rozważ indeks BRIN
. Jest bardzo mały i prawdopodobnie tak szybki jak indeks B-drzewa dla twojego przypadku. (Ale jest tak mały, że znacznie łatwiej pozostanie w pamięci podręcznej i nie będzie tak bardzo wypychał innych danych.)
CREATE INDEX reportimpression_brin_idx ON reportimpression USING BRIN (datelocal);
Być może zainteresuje Cię CLUSTER
lub pg_repack
do fizycznego sortowania wierszy tabeli. pg_repack może to zrobić bez wyłącznych blokad na stole, a nawet bez indeksu btree (wymagane przez CLUSTER ). Ale jest to dodatkowy moduł, który nie jest dostarczany ze standardową dystrybucją Postgresa.
Powiązane:
- Optymalizuj usuwanie osieroconych rekordów Postgres
- Jak odzyskać miejsce na dysku po usunięciu bez odbudowy tabeli?
