Ergebnis 1 bis 10 von 10

Thema: Suchzeit - @@ plainto_tsquery

  1. #1
    strippenzieher ist offline Benutzer
    Registriert seit
    22.01.2011
    Beiträge
    57

    Standard Suchzeit - @@ plainto_tsquery

    Hallo - ich habe:

    Code:
    explain analyse SELECT editionid 
    FROM search_book sb
    WHERE textsearchable_index_gin @@ plainto_tsquery('german','himmel');
    und erhielt dann:

    Code:
    QUERY PLAN                                                           
    --------------------------------------------------------------------------------------------------------------------------------
     Bitmap Heap Scan on search_book sb  (cost=306.70..13726.65 rows=7206 width=4) (actual time=1.253..11338.155 rows=1762 loops=1)
        Recheck Cond: (textsearchable_index_gin @@ '''himmel'''::tsquery)
         ->  Bitmap Index Scan on idx_gin1  (cost=0.00..304.89 rows=7206 width=0) (actual time=0.914..0.914 rows=2783 loops=1)
                Index Cond: (textsearchable_index_gin @@ '''himmel'''::tsquery)
     Total runtime: 11339.476 ms
    (5 Zeilen)
    Meine Frage - mir scheint das 'Recheck Cond' braucht recht lange ohne dass ich überhaupt weiß was das tut. Weiß das jemand? Und wie bekomme ich das schneller - so geht es ja nicht. Der Suchindex enthält ca. 11 mio. kurze (um die 6 Wörter) Einträge.

    Danke für Hinweise!

  2. #2
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.465

    Standard

    Zitat Zitat von strippenzieher Beitrag anzeigen
    Hallo - ich habe:

    Code:
    explain analyse SELECT editionid 
    FROM search_book sb
    WHERE textsearchable_index_gin @@ plainto_tsquery('german','himmel');
    und erhielt dann:

    Code:
    QUERY PLAN                                                           
    --------------------------------------------------------------------------------------------------------------------------------
     Bitmap Heap Scan on search_book sb  (cost=306.70..13726.65 rows=7206 width=4) (actual time=1.253..11338.155 rows=1762 loops=1)
        Recheck Cond: (textsearchable_index_gin @@ '''himmel'''::tsquery)
         ->  Bitmap Index Scan on idx_gin1  (cost=0.00..304.89 rows=7206 width=0) (actual time=0.914..0.914 rows=2783 loops=1)
                Index Cond: (textsearchable_index_gin @@ '''himmel'''::tsquery)
     Total runtime: 11339.476 ms
    (5 Zeilen)
    Meine Frage - mir scheint das 'Recheck Cond' braucht recht lange ohne dass ich überhaupt weiß was das tut. Weiß das jemand? Und wie bekomme ich das schneller - so geht es ja nicht. Der Suchindex enthält ca. 11 mio. kurze (um die 6 Wörter) Einträge.

    Danke für Hinweise!
    Ein 'Recheck Condition' prüft nochmals die Bedingung, daher der Name ;-)

    Ein Bitmap Index Scan hat 'keine Ahnung', ob die Tupel wirklich (in dieser Transaktion) gültig sind, außerdem (und das ist das eigentliche Recheck) ist ein Bitmap Index Scan in der Lage, aus einzelnen Indexen eine Bitmap der jeweil gültigen Bedingungen über alle Tupel aufzustellen. Bein 'Recheck' wird dann über diese Bitmap geprüft, welche Tupel denn nun wirklich die komplette Bedingung erfüllen - und dem 'Bitmap Heap Scan' übergeben.

    Dein 'Recheck' da läuft also etwa zwischen 0.914 ... 1.253, was Zeit braucht ist eher das Lesen der 1762 Tupel aus dem Heap (also der Tabelle selbst), ich schätze mal, die Tabelle ist deutlich größer und die Tupel wild verteilt.

    Evtl. wäre ein 'normaler' Indexscan schneller, das könntest Du testen (mal bitmap index scan abschalten), wäre nett, wenn Du das mal probierst und hier zeigst.


    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  3. #3
    strippenzieher ist offline Benutzer
    Registriert seit
    22.01.2011
    Beiträge
    57

    Standard

    ziemlich versptätet, aber hier kommen die Ergebnisse:

    Ich habe den bitmap index scan mittles
    Code:
    set enable_bitmapscan to off;
    abgeschaltet und erhalte folgendes Ergebnis wenn ich die drei Suchen schnell hintereinander ausführe:
    Code:
    explain analyse SELECT editionid
    FROM search_book sb
    WHERE textsearchable_index_gin @@ plainto_tsquery('german','liebe');
                                                           QUERY PLAN                                                        
    -------------------------------------------------------------------------------------------------------------------------
     Seq Scan on search_book sb  (cost=0.00..1453599.27 rows=6504 width=4) (actual time=41.037..41128.515 rows=4948 loops=1)
       Filter: (textsearchable_index_gin @@ '''lieb'''::tsquery)
     Total runtime: 41132.706 ms
    (3 Zeilen)
    Code:
    explain analyse SELECT editionid
    FROM search_book sb
    WHERE textsearchable_index_gin @@ plainto_tsquery('german','himmel');
                                                          QUERY PLAN                                                       
    -----------------------------------------------------------------------------------------------------------------------
     Seq Scan on search_book sb  (cost=0.00..1453599.27 rows=6504 width=4) (actual time=4.651..3665.698 rows=1775 loops=1)
       Filter: (textsearchable_index_gin @@ '''himmel'''::tsquery)
     Total runtime: 3667.116 ms
    (3 Zeilen)
    Code:
    explain analyse SELECT editionid
    FROM search_book sb
    WHERE textsearchable_index_gin @@ plainto_tsquery('german','liebe');
                                                          QUERY PLAN                                                       
    -----------------------------------------------------------------------------------------------------------------------
     Seq Scan on search_book sb  (cost=0.00..1453599.27 rows=6504 width=4) (actual time=1.607..3203.822 rows=4948 loops=1)
       Filter: (textsearchable_index_gin @@ '''lieb'''::tsquery)
     Total runtime: 3207.170 ms
    (3 Zeilen)
    Ich gehe mal davon aus, dass das Durchsuchen mit bitmap index scan also schneller geht. Komisch ist, wenn ich bei aktivem bitmap index scan eine Weile nichts gesucht habe komme ich auf die langen Suchzeiten, wenn kurz vorher eine Suche erfolge, dann ist die Suchzeit unter einer Sekunde. Die Tabelle enthält etwa 10 mio. Zeilen. Bei deaktiviertem bitmap index scan komme ich bei der ersten Suche wie zu sehen auch auf sehr viel längere Suchzeiten. Schmeißt postgres den Suchindex irgenwann aus dem Cache? Oder wie ist die Differenz zwischen ersten und folgenden Suchen zu erklären?

  4. #4
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.465

    Standard

    Zitat Zitat von strippenzieher Beitrag anzeigen
    Schmeißt postgres den Suchindex irgenwann aus dem Cache?
    Ja.


    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  5. #5
    strippenzieher ist offline Benutzer
    Registriert seit
    22.01.2011
    Beiträge
    57

    Standard

    Lässt sich das denn für gezielt diesen Suchindex verhindern?

  6. #6
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.055

    Standard

    Zitat Zitat von strippenzieher Beitrag anzeigen
    Lässt sich das denn für gezielt diesen Suchindex verhindern?
    Den Index - bzw. die Suche - häufiger verwenden.
    Oder einen größeren Cache kaufen. Btw, das Betriebssystem nutzt den Rest des RAM auch als Cache, ungefragt, kostengünstig, effektiv.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  7. #7
    strippenzieher ist offline Benutzer
    Registriert seit
    22.01.2011
    Beiträge
    57

    Standard

    Schade, das fänd ich mal nen nettes Feature bestimmen zu können, den Index als letztes aus dem Cache zu schmeißen. Naja... Danke für die Hinweise!

  8. #8
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.465

    Standard

    Zitat Zitat von strippenzieher Beitrag anzeigen
    Schade, das fänd ich mal nen nettes Feature bestimmen zu können, den Index als letztes aus dem Cache zu schmeißen. Naja... Danke für die Hinweise!
    Über die Frage kann man diskutieren. Angenommen, Du hast eine große Tabelle und einen großen Index (ja, Indexe können groß werden), und leider so doofe Abfragen, daß diese immer einen Seq-Scan nach sich ziehen. Leider klebt aber der große Index im RAM, so daß die Tabelle immer und immer wieder von der Pladde geklaubt werden muß. So what?

    Ich sag mal so: es gibt (bei reinen, dedizierten PG-Servern) so die Regel, 25% RAM als Shared Buffer zu nutzen, und das auch nur bis etwa 8 GByte. Den Rest dem OS als Cache geben. Ich denke mal, das sind unterm Strich Erfahrungen, die sich bewährt haben. Wird Dein Index oft genutzt, so wird das OS (als Instanz, welche ca. 75% RAM überwacht) hoffentlich smart genug sein, die richtige Entscheidung zu treffen und dem Index-File eine gewisse Priorität einräumen, wenn sinnvoll.

    Merke: Indexe nützen nicht immer. PG bietet da übrigens auch sinnvolle Statistiken.


    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  9. #9
    strippenzieher ist offline Benutzer
    Registriert seit
    22.01.2011
    Beiträge
    57

    Standard

    Zitat Zitat von akretschmer Beitrag anzeigen
    Über die Frage kann man diskutieren. Angenommen, Du hast eine große Tabelle und einen großen Index (ja, Indexe können groß werden), und leider so doofe Abfragen, daß diese immer einen Seq-Scan nach sich ziehen. Leider klebt aber der große Index im RAM, so daß die Tabelle immer und immer wieder von der Pladde geklaubt werden muß. So what?
    Wenn ich das richtig verstehe, ist der 'Recheck' von oben die Prüfung der Tabelle. Um also den Bitmap Index Scan zu beschleunigen, wird der Index im Cache gebraucht - und für einen schnellen 'Recheck' sollte die Tabelle im Cache sein? Und wenn beides flott gehen soll brauch ich RAM der beides schluckt?

    Ich sag mal so: es gibt (bei reinen, dedizierten PG-Servern) so die Regel, 25% RAM als Shared Buffer zu nutzen, und das auch nur bis etwa 8 GByte. Den Rest dem OS als Cache geben. Ich denke mal, das sind unterm Strich Erfahrungen, die sich bewährt haben. Wird Dein Index oft genutzt, so wird das OS (als Instanz, welche ca. 75% RAM überwacht) hoffentlich smart genug sein, die richtige Entscheidung zu treffen und dem Index-File eine gewisse Priorität einräumen, wenn sinnvoll.
    Hast du vielleicht einen Link wo erläutert wird, inwiefern Buffer und restliches RAM unterschiedlich aus Sicht des Caches behandelt werden?

  10. #10
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.465

    Standard

    Zitat Zitat von strippenzieher Beitrag anzeigen
    Wenn ich das richtig verstehe, ist der 'Recheck' von oben die Prüfung der Tabelle. Um also den Bitmap Index Scan zu beschleunigen, wird der Index im Cache gebraucht - und für einen schnellen 'Recheck' sollte die Tabelle im Cache sein? Und wenn beides flott gehen soll brauch ich RAM der beides schluckt?
    Ja, erst 9.2 wird Index Only - Scans bringen. Bis dahin ist IMMER auch die Tabelle selbst zu befragen. Aber Index Only - Scans sind nicht trivial, ich muß da auch noch mal mich reinlesen, was da genau abläuft.

    Allgemein gilt: RAM ist durch nichts zu ersetzen. Außer durch mehr RAM.

    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum