Det finns några viktiga skäl till att använda tabellarv i postgres.
Låt oss säga att vi har några tabeller som behövs för statistik, som skapas och fylls i varje månad:
statistics
- statistics_2010_04 (inherits statistics)
- statistics_2010_05 (inherits statistics)
I detta exempel har vi 2 000 000 rader i varje tabell. Varje tabell har en CHECK-begränsning för att säkerställa att endast data för den matchande månaden lagras i den.
Så vad gör arvet till en cool funktion - varför är det coolt att dela upp data?
- PRESTANDA:När vi väljer data VÄLJER vi * FRÅN statistik WHERE datum MELLAN x och Y, och Postgres använder bara tabellerna där det är vettigt. T.ex. VÄLJ * FRÅN statistik VAR datum MELLAN '2010-04-01' OCH '2010-04-15' skannar bara tabellstatistiken_2010_04, alla andra tabeller kommer inte att beröras - snabbt!
- Indexstorlek:Vi har ingen stor fet tabell med ett stort fettindex på kolumndatum. Vi har små tabeller per månad, med små index - snabbare läsning.
- Underhåll:Vi kan köra vakuum fullt, återindexera, klustera på varje månadstabell utan att låsa all annan data
För korrekt användning av tabellärvning som prestationsförstärkare, titta i postgresql-manualen. Du måste ställa in CHECK-begränsningar på varje tabell för att tala om för databasen på vilken nyckel din data delas (partitioneras).
Jag använder mig mycket av tabellarv, speciellt när det kommer till att lagra loggdata grupperade efter månad. Tips:Om du lagrar data, som aldrig kommer att ändras (loggdata), skapa eller indexera med CREATE INDEX ON () WITH(fillfactor=100); Det betyder att inget utrymme för uppdateringar kommer att reserveras i indexet - indexet är mindre på disken.
UPPDATERING:fillfactor standard är 100, från http://www.postgresql.org/docs/9.1/static/sql-createtable.html:
Fyllningsfaktorn för en tabell är en procentandel mellan 10 och 100. 100 (fullständig packning) är standard