Una vista materializzata è la strada da percorrere per quello che hai delineato. L'esecuzione di query sui dati di sola lettura degli ultimi mesi funziona senza aggiornarli. Potresti voler considerare il mese corrente in un caso speciale se hai bisogno di coprire anche quello.
La query sottostante può comunque trarre vantaggio da un indice e ci sono due direzioni che potresti prendere:
Prima di tutto, indici parziali come hai fatto ora non comprerai molto nel tuo scenario, non ne vale la pena. Se raccogli molti più mesi di dati e principalmente esegui query per mese (e aggiungi/rilascia righe per mese) partizionamento della tabella potrebbe essere un'idea, quindi hai anche i tuoi indici partizionati automaticamente. Tuttavia, prenderei in considerazione Postgres 11 o anche il prossimo Postgres 12.)
Se le tue righe sono larghe , crea un indice che consenta scansioni solo indice . Come:
CREATE INDEX reportimpression_covering_idx ON reportimpression(datelocal, views, gender);
Correlati:
Oppure INCLUDE colonne aggiuntive in Postgres 11 o versioni successive:
CREATE INDEX reportimpression_covering_idx ON reportimpression(datelocal) INCLUDE (views, gender);
Altro , se le tue righe sono ordinate fisicamente per datelocal , considera un indice BRIN
. È estremamente piccolo e probabilmente veloce quanto un indice B-tree per il tuo caso. (Ma essendo così piccolo rimarrà memorizzato nella cache molto più facilmente e non espellerà così tanto altri dati.)
CREATE INDEX reportimpression_brin_idx ON reportimpression USING BRIN (datelocal);
Potresti essere interessato a CLUSTER
o pg_repack
per ordinare fisicamente le righe della tabella. pg_repack può farlo senza lock esclusivi sul tavolo e anche senza un indice btree (richiesto da CLUSTER ). Ma è un modulo aggiuntivo non fornito con la distribuzione standard di Postgres.
Correlati:
- Ottimizza l'eliminazione di Postgres dei record orfani
- Come recuperare spazio su disco dopo l'eliminazione senza ricostruire la tabella?
