Postgresql - wydajność Opcje

[Ziels]

Witam

Jakiś czas temu opisałem problem z ładowaniem wpisów do bazy - rozwiązaniem okazał się serwer dedykowany i podzielenie pliku na pakiety (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Aktualnie mierzę się z takim problemem: baza zawiera 30 mln wpisów i zwykły count zajmuje 8 sekund (tak, wiem, w postgresqlu są wolne, ale bez przesady!). Jak można rozwiązać problem wydajności przy tej ilości danych? Czytałem trochę o partycjonowaniu tabel, trochę o widokach - jednak nie wiem które rozwiązanie przyniesie największe korzyści wydajnościowe. Tabela zawiera 4 kolumny - 3 integery i 1 boolean.

Jeśli to ma znaczenie: wyszukiwanie w niej planowo ma się opierać na czymś takim: WHERE col1 = 5 AND col2 BETWEEN 400 AND 94200

[Ziels]

Dzięki za odpowiedź (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

VACUUM - dzisiaj całą bazę postawiłem i uzupełniłem ją danymi, potem zrobiłem VACUUM FULL.

Typ indeksu - ok, dzięki, zmienię (mam nadzieję że da się bez czyszczenia tabeli (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) ) i sprawdzę wyszukiwanie ponownie.

co do count(1) - nie wiedziałem nawet, dzięki (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) niestety nie zmienia zbyt wiele :/

Kod

portal=# explain analyze select count(1) from table;
                                                               QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------
Aggregate  (cost=495164.33..495164.34 rows=1 width=0) (actual time=8134.547..8134.547 rows=1 loops=1)
   ->  Seq Scan on table  (cost=0.00..426028.26 rows=27654426 width=0) (actual time=0.009..4575.271 rows=27654426 loops=1)
Total runtime: 8134.594 ms
(3 rows)

portal=# explain analyze select count(*) from table;
                                                               QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------
Aggregate  (cost=495164.33..495164.34 rows=1 width=0) (actual time=8023.854..8023.855 rows=1 loops=1)
   ->  Seq Scan on table  (cost=0.00..426028.26 rows=27654426 width=0) (actual time=0.013..4521.300 rows=27654426 loops=1)
Total runtime: 8023.903 ms
(3 rows)

Dziwi mnie taki rezultat, szczególnie że komputer to nie taki słaby serwer dedykowany ze świeżo postawionym systemem. Zgodnie ze wskazówkami z wiki postgresqla zmieniłem mu limity pamięci ale to również nie pomogło. Całość jest na Ubuntu server 8.04 na ReiserFS - wcześniej był umieszczony na ext3 i był identyczny problem.



=========EDIT==========
Indexes:
"table_pkey" PRIMARY KEY, btree (id) CLUSTER

Czyli porządany typ już jest. Pozostałe dwie kolumny numeryczne to po prostu klucze obce.

Ten post edytował Ziels 6.08.2008, 17:10:21