Wypowiedzi
-
Borys M.:
Chodzi mi o to że takie spływające nieustannie inserty będą psuć indeksy i PostgreSQL może mieć problem z ich nieustannym
odbudowywaniem.
No taki problem może się zdarzyć, ale właśnie temu zapobiega partycjonowanie, ponieważ indeks jest tworzony na tabeli dziedziczącej, czyli tylko na fragmencie danych i dzięki temu ma ograniczoną wielkość:)
Następną rzeczą, o której warto pomyśleć to zmiana wartości parametru FILLFACTOR przy CREATE INDEX, który defaultowo wynosi 90%.
http://www.postgresql.org/docs/8.3/static/sql-createin...
Ustawienie go na niższą wartość zmniejsza początkowe wypełnienie drzewa btree, co opóźnia późniejsze ewentualne problemy z przepełnianiem gałęzi w przypadku wielu insertów/updatów do tabeli.Wojciech Bublik edytował(a) ten post dnia 08.12.09 o godzinie 21:15
-
Witam,
Też sądze, że Postgres sobie z tym poradzi:)
Warto zwrócić uwagę, aby aplikacja nie wykonywała zbędnych updatów na tak dużych tabelach, po to aby unikać potrzeby robienia na nich Vacuum full oraz warto zastanowić się nad spartycjonowaniem tych tabel.
Ułatwi to zarządzanie danymi i indeksami oraz powinno przyspiszyc wyszukiwanie np o tsvector jeśli podasz do selecta dodatkowe warunki, wg których są tworzone partycje.
http://www.postgresql.org/docs/8.3/interactive/ddl-par...
http://www.postgresql.org/docs/8.3/interactive/ddl-inh...
Myślę, że optymalnie byłoby spartycjonować tabele tak, aby każda zajmowała po kilkanaście GB.
Kolejna sprawa to postgresql.conf... Nie zapomnij o tuningu parametrów takich jak: effective_cache_size, work_mem, shared_buffers:) oraz jeśli baza danych jest "bombardowana" insertami to na pewno trzeba będzie zwiększyć checkpoint_segments np do 8.
Pozdrawiam
Wojtek
