Schnellste Methode für fuzzy suche

Hi,
ich habe die Funktion Similarity getestet mit einem Gist Index aus Trigrammen.
Ich muss dabei bis zu mehrer millionen sätze, die in der DB gespeichert sind mit einem Satz den ich eingebe vergleichen.
Es ist leider zu langsam.
Müsste dies eigentlich schnell genug gehen?
Gibt es schnellere alternativen?

Wird der Index genutzt?

Ich denke schon. Es ist viel schneller als vorher. Wie kann ich das überprüfen?

Explain nutzen.

array(1) { [“QUERY PLAN”]=> string(45) “Sort (cost=289.49…289.68 rows=76 width=118)” }
array(1) { [“QUERY PLAN”]=> string(50) " Sort Key: (similarity(spalte, ‘guten tag.’::text))" }
array(1) { [“QUERY PLAN”]=> string(78) " -> Bitmap Heap Scan on table (cost=29.09…287.12 rows=76 width=118)" }
array(1) { [“QUERY PLAN”]=> string(49) " Recheck Cond: (dede % ‘guten tag.’::text)" }
array(1) { [“QUERY PLAN”]=> string(85) " -> Bitmap Index Scan on table_idx (cost=0.00…29.07 rows=76 width=0)" }
array(1) { [“QUERY PLAN”]=> string(53) " Index Cond: (spalte % ‘guten tag.’::text)" }

Bist auf dem richtigen Weg :wink:

Mach das mal nach Möglichkeit in psql direkt, nutze die Form EXPLAIN ANALYSE, und zeige das ganze dann in Code-Blöcken, damit es besser formatiert ist.
Aber der Index wird erst einmal benutzt.

Das habe ich bekommen:
Sort (cost=289.49…289.68 rows=76 width=118) (actual time=118.125…118.126 rows=2 loops=1)
Sort Key: (similarity(column, ‘guten tag’::text))
Sort Method: quicksort Memory: 17kB
-> Bitmap Heap Scan on table (cost=29.09…287.12 rows=76 width=118) (actual time=118.076…118.095 rows=2 loops=1)
Recheck Cond: (column % ‘guten tag’::text)
-> Bitmap Index Scan on table_idx (cost=0.00…29.07 rows=76 width=0) (actual time=117.894…117.894 rows=2 loops=1)
Index Cond: (column % ‘guten tag’::text)
total runtime ca. 120ms

Nun ja, 0.12Sekunden, Sortierung im RAM, geschätzte zu tatsächlichen Rows passen halbwegs. Für mehrere Millionen Zeilen doch okay, oder?

sind bis jetzt nur 75000 Zeilen. Und ich habe nur nach “guten tag” gesucht. Nicht nach mehreren sätzen

ist es meine Schuld, wenn Du unpassende Dinge hier zeigst?

Nein natürlich nicht. Ich hab bisher nicht mehr Sätze in der DB. Die bekomme ich erst mit der Zeit. Ich dachte das genügt als Beispiel.

Eine Index-Suche wird nicht linear länger dauern mit Anzahl der Datensätze, insofern ist Deine Angst eher unbegründet. Es kann sich natürlich der Plan ändern, wenn das Select sich ändert.

Ach ja: wieviel RAM hat die Kiste, ist die Config an die Hardware angepaßt (Shared Buffers etc.)

Die Config ist noch nicht angepasst. Das ganze läuft probeweise zum schreiben auf meinem pc. Der hat zzt. 4 gig ram

PG nutzt per Default nur 32MB RAM oder so, da muß man sich auch nicht wundern…

gut zu wissen^^
Wieviel oder welchen Anteil vom verfügbaren RAM macht es sinn zu nutzen?
Ich habe die 75000 Zeilen jetzt mehrmals in die DB eingelesen. Bisher ist der Rechenaufwand halbwegs linear, aber das liegt denke ich daran dass es dieselben Daten sind.

Man hört oft ca. 25% RAM für shared buffers, aber nicht mehr als 8 oder 10 GB.

Habs in der postgresql.conf auf 512MB gesetzt testweise und neugestartet. Tut sich jedoch nichts. Hab ich was falsch gemacht?



explain (analyse, buffers) ...

Die Ausgabe vergleichst Du bei unterschiedlichen shared buffers - Werten.

Andreas

Es ändert sich nichts /:
Was genau muss ich neu starten damit der die postgresql.conf neu läd?

PostgreSQL. Also den DB-Server. Was auch sonst?

In psql kannst Du via “show shared_buffers;” prüfen, auf was es steht.