kilkukrotny join dużych tabel

[shyha]

a może to być kwestia szybkości odczytu dysku?

Ten parametr jest jednym z najbardziej kluczowych
Dodam tylko, że nie jestem ekspertem w tuningu baz danych

[bies]

Załóżmy, że struktura jest taka jak podał Shyha. Załóżmy, że jedyny indeks jest na polu ,,slowo''. Spróbuj tak:

Kod:

Select
        id_dok,
        slowo
from indeks
where
        slowo in (slowo_1, ..., slowo_n)
order by id_dok

A następnie przejdź kursorem (albo po stronie bazy - PostreSQL ma jakiś odpowiednik PLSQL-a, albo po stronie aplikacji) i wybierz tylko te id o odpowiedniej liczności.

// edit
Aha, IMO wyszukiwanie dokumentów po słowach kluczowych to zdecydowanie nie domena relacyjnej bazy danych - tu bardziej przydaje się struktura drzewa (grafu). Może użyj jakiejś dedykowanej biblioteki (np. Lucene).

[Goliatus]

Jeśli jedyny indeks jest na "słowo" to sortowanie po id_dok również da zły efekt.

Aha, IMO wyszukiwanie dokumentów po słowach kluczowych to zdecydowanie nie domena relacyjnej bazy danych - tu bardziej przydaje się struktura drzewa (grafu). Może użyj jakiejś dedykowanej biblioteki (np. Lucene).

No tak ale to nie tylko przeszukiwanie tekstu, ale również przeszukiwanie obiektów o różnych parametrach. Zamiast robić 100 tabel dla każdej kategorii obiektów, zrobiłem jedną:
(id_obiekt, id_typ_parametru, wartosc)

Nie wiem czy to wlasciwy sposob uzywania baz danych, ale uproscilo to wiele spraw.

[shyha]

Jeśli jedyny indeks jest na "słowo" to sortowanie po id_dok również da zły efekt.

Nie - po prostu odfiltruje przy użyciu indeksu. Bies dał ci rozwiązanie, w którym wyznaczenie liczności rekordów i filtrowanie po niej zrzucone są na twoje barki


// edit: aaaaaaaaaaaaa inne pola myślałem, że chodzi o to samo

[Goliatus]

No ale jaka gwarancja, że to sortowanie bez używania jakiegoś indeksu nie zamuli?

[bies]

Jeśli jedyny indeks jest na "słowo" to sortowanie po id_dok również da zły efekt.

Tak, mea culpa, indeks na id_dok też się pewnie przyda. Czyli potrzebne będą raczej dwa indeksy. Poza tym, sprawdź. ;P

// edit
Może warto nawet zrobić CLUSTER (tj. robić co jakiś czas) po tym indeksie.

[Goliatus]

no sprawdziłem działa dobrze(filtrowanie we własnym zakresie pozwoli na pokazywanie wyników na bieżąco, o co w sumie mi chodziło), indeks na id_dok jest, ale nie jest używany

[bies]

Ok, jeśli miałbyś trochę czasu to spróbuj zrobić to tak.
1) Stwórz dwie tabele, jedną fizycznie posortowaną (cluster), drugą bez indeksu (skoro działa dobrze - trochę się zdziwiłem, spodziewałem się raczej, że indeks będzie pomocny).
2) Bieżące dane wpisuj do drugiej.
3) W ,,trybie nocnego przetwarzania'' przerzucaj dane z drugiej do pierwszej i znowu cluster.
4) Wyszukuj w obu w ten sam sposób a w programie imperatywnym przejdź dwoma kroczącymi kursorami - b. prosty i szybki algorytm.

// edit
A w ogóle zobacz ,,Notes'' w dokumentacji do CLUSTER - tam jest ciekawy mechanizm który może w ogóle wyeliminować sortowanie z pierwszej tabeli.

[Reg]

Skoro to ma być wyszukiwanie słów kluczowych, to nie myślałeś może, żeby spróbować indeksów pełnotekstowych?

[Goliatus]

Poczytałem troche o tsearch2, że ludzie mają z tym wydajnościowe problemy, a że nie dysponuje super sprzętem to wolę nie ryzykować i sklecic samemu coś prostszego.

[JCoder]

Przekombinowujecie
CLUSTER tabela_idx_b ON tabela_b;

Powinno przyspieszyć o rząd wielkości.

 

[skowronkow]

nie mowiac juz o tym ze jak napisal bies jest to typowe zastosowanie fulltext search... ale staruski temat;p