Denna siffra är inte så hög som du tror. I nuvarande arbete lagrar vi statistikdata för webbplatser och det totala antalet rader vi har är mycket högre. Och i tidigare jobb arbetade jag med pg-databasen som samlade in statistik från mobilnätet och den samlade in ~2 miljarder poster per dag. Så var inte rädd för miljarder i antal poster.
Du kommer definitivt att behöva partitionera data - troligen på dagarna. Med denna mängd data kan du hitta index ganska värdelösa. Beror på plan du kommer att se i EXPLAIN kommandoutgång. Till exempel att telco-appen inte använde några index alls eftersom de bara skulle sakta ner hela motorn.
En annan fråga är hur snabba svar på frågor du behöver. Och vilka steg i granularitet (summor över timmar/dagar/veckor etc) för frågor du tillåter för användare. Du kan till och med behöva göra några aggregationer för granulariteter som vecka eller månad eller kvartal.
Tillägg:
Dessa ~2 miljarder poster per dag i den telekomappen tog ~290 GB per dag. Och det innebar infogning av ~23000 poster per sekund med hjälp av bulkinfogningar med kommandot COPY. Varje bulk var flera tusentals poster. Rådata var uppdelade efter minuter. För att undvika diskväntningar hade db 4 tabellutrymmen på 4 olika diskar/arrayer och partitioner var fördelade över dem. PostreSQL kunde hantera allt utan problem. Så du bör också tänka på rätt HW-konfiguration.
En bra idé är också att flytta pg_xlog-katalogen till en separat disk eller array. Nej bara ett annat filsystem. Det hela måste vara separat HW. SSD:er kan jag rekommendera endast i arrayer med korrekt felkontroll. På sistone har vi haft problem med korrupt databas på singel SSD.