Uma visualização materializada é o caminho a percorrer para o que você descreveu. Consultar os últimos meses de dados somente leitura funciona sem atualizá-los. Você pode querer especializar o mês atual se precisar cobrir isso também.
A consulta subjacente ainda pode se beneficiar de um índice e há duas direções que você pode seguir:
Primeiro, índices parciais como você tem agora não vai comprar muito no seu cenário, não vale a pena. Se você coletar muitos outros meses de dados e principalmente consultar por mês (e adicionar / descartar linhas por mês) particionamento de tabela pode ser uma ideia, então você também tem seus índices particionados automaticamente. Eu consideraria o Postgres 11 ou mesmo o próximo Postgres 12 para isso.)
Se suas linhas forem largas , crie um índice que permita verificações somente de índice . Curti:
CREATE INDEX reportimpression_covering_idx ON reportimpression(datelocal, views, gender);
Relacionado:
Ou
INCLUDE colunas adicionais no Postgres 11 ou posterior:CREATE INDEX reportimpression_covering_idx ON reportimpression(datelocal) INCLUDE (views, gender);
Mais , se suas linhas forem classificadas fisicamente por
datelocal , considere um índice BRIN
. É extremamente pequeno e provavelmente tão rápido quanto um índice de árvore B para o seu caso. (Mas, sendo tão pequeno, ficará armazenado em cache com muito mais facilidade e não enviará outros dados.) CREATE INDEX reportimpression_brin_idx ON reportimpression USING BRIN (datelocal);
Você pode estar interessado em
CLUSTER
ou pg_repack
para classificar fisicamente as linhas da tabela. pg_repack pode fazê-lo sem bloqueios exclusivos na tabela e mesmo sem um índice btree (requerido por CLUSTER ). Mas é um módulo adicional não fornecido com a distribuição padrão do Postgres. Relacionado:
- Otimizar a exclusão do Postgres de registros órfãos
- Como recuperar espaço em disco após a exclusão sem reconstruir a tabela?
