[postgresql] szukanie po indeksie tsearch'owym wlecze sie - da siejakos przyspieszyc?
Wojciech Jukowski - 03-07-2006 00:02
[postgresql] szukanie po indeksie tsearch'owym wlecze sie - da siejakos przyspieszyc?
Hej
Środowisko: postgresql 7.4.8, tsearch2, język polski (słownik ispellowy).
Dane: 260 tys rekordów, do kilku tysięcy słów w jednym rekordzie. W
sumie 61.000 różnych słów, w 3 wagach (tytuł, opis, treść).
Zapytania wyszukujące po indeksie ts działają tak wolno, że nie da się
praktycznie korzystać z aplikacji je wywołujących. Nawet proste:
SELECT count(*)
FROM wyszukiwarka
WHERE ts_vector_szukaj
@@ to_tsquery('default_polish', 'pomidor:ABC' )
zwraca wynik po 11-20 sekundach.
Czy da się coś z tym zrobić? Jak można przyśpieszyć działanie zapytań?
Może ktoś już zetknął się z problem zwolnienia działania tsearch
(wcześniej analogicznie zapytanie potrafiło działać w czasie <1s). Czy
jakieś inne indeksy na relacji mogą mieć jakieś znaczenie? Może rozmiar
na dysku?.. Trochę błądzimy i szczerze powiedziawszy nie bardzo mamy
pomysł gdzie szukać rozwiązania.
Z góry dzięki za wasze sugestie
PS
Reindeksacja wektora gist, jak i całej tabelki nie pomaga.
Pozdrawiam,
Wojtek
Adam Buraczewski - 03-07-2006 00:02
Wojciech Jukowski <wojciech.jukowski@infor.pl> wrote:
> Zapytania wyszukujące po indeksie ts działają tak wolno, że nie da się
> praktycznie korzystać z aplikacji je wywołujących. Nawet proste:
>
> SELECT count(*)
> FROM wyszukiwarka
> WHERE ts_vector_szukaj
> @@ to_tsquery('default_polish', 'pomidor:ABC' )
>
> zwraca wynik po 11-20 sekundach.
Co wyświetla EXPLAIN ANALYZE? Czy kiedy to zapytanie działało szybko,
to też było tyle danych w tabeli?
> Reindeksacja wektora gist, jak i całej tabelki nie pomaga.
Tak tylko dla porządku zapytam: a VACUUM FULL ANALYZE próbowałeś?
Jeżeli to jest bardzo często UPDATEowana tabela, to możliwe że jest
w niej dużo wersji wierszy i tak naprawdę nie ma ich 260 tys., lecz
kilka milionów.
Pozdrawiam!
--
Adam Buraczewski <adamb (at) nor (dot) pl> * Linux user #165585
GCS/TW d- s-:+>+:- a C+++(++++) UL++++$ P++ L++++ E++ W+ N++ o? K w--
O M- V- PS+ !PE Y PGP+ t+ 5 X+ R tv- b+ DI D G++ e+++>++++ h r+>++ y?
Wojciech Jukowski - 04-07-2006 00:56
Witam
Adam Buraczewski napisał(a):
>> SELECT count(*)
>> FROM wyszukiwarka
>> WHERE ts_vector_szukaj
>> @@ to_tsquery('default_polish', 'pomidor:ABC' )
>>
>> zwraca wynik po 11-20 sekundach.
>
> Co wyświetla EXPLAIN ANALYZE? Czy kiedy to zapytanie działało szybko,
> to też było tyle danych w tabeli?
Wydaję mi się, że gdy było ok 150 tys rekordów działało szybciej. Od
tego czasu doszły dane i dodaliśmy kilka indeksów (uwzględnienie
kryteriów wyszukiwania - np dokumenty tylko z ostatnich 2 miesięcy).
Troszkę więcej o środowisku:
PostgreSQL 7.4.8 on i386-redhat-linux-gnu, compiled by GCC
i386-redhat-linux-gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22))
Słownik ~60.000 słów (~270.000 rekordów). Słownik budowany jest z 3
kolumn stąd 3 wagi ABC.
EXPLAIN ANALYZE
select count(*)
from wyszukiwarka_tmp where ts_vector_szukaj @@
to_tsquery('default_polish','ustawa:ABC');
Aggregate
(cost=811.17..811.17 rows=1 width=0)
(actual time=70937.878..70937.879 rows=1 loops=1)
-> Index Scan using wyszukiwarka_tmp_idx
on wyszukiwarka_tmp
(cost=0.00..810.68 rows=197 width=0)
(actual time=735.454..70920.452 rows=11402 loops=1)
Index Cond: (ts_vector_szukaj @@ '\'ustawa\':ABC'::tsquery)
Filter: (ts_vector_szukaj @@ '\'ustawa\':ABC'::tsquery)
Total runtime: 70937.980 ms
>
>> Reindeksacja wektora gist, jak i całej tabelki nie pomaga.
>
> Tak tylko dla porządku zapytam: a VACUUM FULL ANALYZE próbowałeś?
> Jeżeli to jest bardzo często UPDATEowana tabela, to możliwe że jest
> w niej dużo wersji wierszy i tak naprawdę nie ma ich 260 tys., lecz
> kilka milionów.
Zmiany przyrostowe (0-5%) ale i tak co noc robimy pełnego VACUUM'a oraz
dodatkowo reindeksacje. Pomaga ale to różnica 300s -> 30 s/ zapytanie.
Nadal nie widzę możliwości korzystania z tak powoli działającej
wyszukiwarki.
Wierzymy, że dzięki optymalizacji samej bazy lub danych mechanizm
tsearcha będzie rozwiązaniem, którego szukamy. Każda porada jest dla nas
bardzo cenna :)
Pozdrawiam,
Wojtek
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
[PostgreSQL] - jak =?ISO-8859-2?Q?zabezpieczy=E6_interesy_tw?==?ISO-8859-2?Q?=F3rcy_systemu_=3F=3F=3F?=
postgresql - int/int
postgresql Select count(*) czy raczej Select count(ID)
[PostgreSQL] jak =?ISO-8859-2?Q?pobra=E6_warto=B6=E6_zwracan?==?ISO-8859-2?Q?=B1_przez_funkcj=EA=3F?=
[postgresql] INSERT OR UPDATE - jak =?ISO-8859-2?Q?b=EAdzie_na?==?ISO-8859-2?Q?jlepiej=3F?=
[postgresql] kilka =?ISO-8859-2?Q?rekord=F3w_subquery_jako_?==?ISO-8859-2?Q?string?=
[PostgreSQL] Jak =?ISO-8859-2?Q?po=B3=B1czy=E6_funkcje_z_w?==?ISO-8859-2?Q?idokiem?=
Postgres - replikcja master-master
Dopasowanie do "najlepszego" dopasowania :) [ PostgreSQL]
Problemy z =?ISO-8859-2?Q?instalacj=B1_PostgreSQL_na_syste?==?ISO-8859-2?Q?mach_Windows?=
zanotowane.pldoc.pisz.plpdf.pisz.plkfia-tek.keep.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
