SlideShare ist ein Scribd-Unternehmen logo
Eine Reise durch den PostgreSQL Optimizer

          Bernd Helmle, bernd.helmle@credativ.de


                             23. August 2010




  Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Am Anfang steht SQL




     SQL = Structured Query Language
     Eigentlich ein Eigenname
     Standardisiert, stetige Weiterentwicklung (SQL99, SQL 2003,
     SQL 2008, SQL/MED)
     Deklarativ, Beschreibend
     KEIN(!) Programmcode




        Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Optimizer? Planer?



  “Finde einen m¨glichst effizienten Weg um das gew¨nschte
                 o                               u
  Resultat korrekt zu liefern”
      Optimizer ein wenig missverst¨ndlich
                                   a
      Planen und “optimieren”
      Liefert Arbeitsanweisungen f¨r den Executor
                                  u
      Fasst diese in einen m¨glichst effizienten “Plan” zusammen
                            o
      Kritischer Faktor: Aufwand um m¨gliche Arbeitsschritte zu
                                      o
      einem guten Plan zu kombinieren




         Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Was passiert im Datenbankserver?




        Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Der Planer (1)



      Planer erh¨lt Query aus dem Rewriter
                a
      Drei Phasen:
        1     Preprocessing Phase (Subqueries, Aggregates,
              WHERE-clauses)
        2     Ermitteln der JOIN-Zugriffspfade (Pfad)
        3     Zusammenfassen der Planknoten, Ausgabe als Plan
      Ein Plan ist das Ergebnis der m¨glichst g¨nstigsten
                                     o         u
      Kombination der einzelnen Zugriffspfade (Nodes)
      Ggf. rekursive Aufrufe des Planers (Subqueries, SubPlan)
      Unterschiedliche Methoden f¨r Phase zwei.
                                 u




            Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Der Planer (3)
  Exhaustive Search
    SELECT *
    FROM a, b, c, d
    WHERE a.col = b.col AND a.col = c.col
          AND a.col = d.col;

    {a,b} {a,c} {a,d}
    ...
    -> {a,b,c} {d}
    -> {d} {a,b,c}
    -> {a,b} {c,d}
    ...

      Ann¨hrend ”Ersch¨pfend”
         a              o
      from collapse limit: Umschreiben von Subqueries in
      JOIN-Liste (Flattening)
      join collapse limit: Umsortieren von expliziten JOINs
         Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Der Planer (4)




  GEQO (Genetic Query Optimizer)
      Semi-Randomisierte Suche
                                    ¨
      Non-deterministische Auswahl (Anderungen in 9.0)
      Gute Gene (Planknoten) werden rekombiniert
  . . . die fittesten “Gene” gewinnen




          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Wie macht der Planer das?




      Heranziehen vermuteter Ergebniszeilen
      (pg class.reltuples)
      Ggf. interpolieren auf Anzahl aktueller phyiskalischer Bl¨cke
                                                               o
      (pg class.relpages)
      Kosten f¨r Planknoten (bspw. Selektivit¨t f¨r Indexscan usw.)
              u                              a u
  . . . und nimmt den billigsten“.
                     ”




          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Wie weiß der Planer das?




     Statistiken, von ANALYZE gesammelt
     Tabellenspezifische Kosten (pg class.reltuples,
     pg class.relpages
     Spaltenstatistiken (pg statistic, pg stats)
     Verstellbare Kostenparameter




        Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Kostenparameter

   1   seq page cost: I/O-Kosten f¨r einen sequentiellen
                                  u
       Block-Lesevorgang
   2   random page cost: I/O-Kosten f¨r einen zuf¨lligen
                                     u           a
       Block-Lesevorgang
   3   effective cache size: Beeinflusst angenomme Cachegr¨ße
                                                         o
       und damit Auswahl von Indexscans
   4   cpu tuple cost: CPU-Kosten f¨r das Verarbeiten einer Zeile
                                   u
       einer Tabelle
   5   cpu index tuple cost: CPU-Kosten f¨r das Verarbeiten
                                         u
       einer Zeile eines Indexes.
   6   cpu operator cost: Operator- und/oder Prozedurkosten
       einer CPU.
   7   cpu tuple fraction: Anteil des ersten Tupel aus einem
       Cursor
          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Kostenberechnung (1)



  Die Kostenfaktoren beeinflussen die Kostenberechnung. F¨r einen
                                                        u
  Sequential Scan erfolgt diese beispielhaft wie folgt:

  Endkosten = (Anzahl Bl¨cke * seq_page_cost)
                        o
   + (Anzahl Tupel * cpu_tuple_cost)

  Startkosten sind 0.00, da keine Maßnahmen f¨r das Erzeugen des
                                             u
  Planknotens n¨tig sind.
                o




         Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Kostenberechnung (2)

  Neben diesem (einfachen) I/O-Kostenmodell verf¨gt der Planer
                                                u
  uber weitere, tiefgreifende Statistiken
  ¨
      pg stats enth¨lt mittels ANALYZE ermittelte Statistiken pro
                   a
      Tabelle und zugeh¨render Spalte
                        o
      null fraq: Anteil NULL-Werte
      avg width: Durchschnittliche Gr¨ße in Bytes
                                     o
      n distinct: Unterschiedliche Werte einer Spalte
      most common vals: H¨ufigste Werte
                         a
      most common freqs: Selektivit¨t der h¨ufigsten Werte
                                   a       a
      histogram bounds: Gruppierung der Spaltenwerte in
      ungef¨hr gleich große Gruppen
           a
      correlation: Verteilung der Daten auf der Platte


         Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Kostenberechnung (3)


  SELECT * FROM pg_stats WHERE tablename = ’tenk1’
         AND attname = ’hundred’;
  -[ RECORD 1 ]-----+------------------------------------------
  schemaname        | public
  tablename         | tenk1
  attname           | hundred
  null_frac         | 0
  avg_width         | 4
  n_distinct        | 100
  most_common_vals | {41,26,64,97}
  most_common_freqs | {0.0136667,0.0133333,0.0133333,0.0126667}
  histogram_bounds | {0,10,19,30,39,50,60,70,79,89,99}
  correlation       | 0.0156366




          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Pl¨ne lesen (1)
  a




      Plan besteht aus Planknoten: jeweils eine in sich
      abgeschlossene Arbeitseinheit
      Die Schachtelung gibt die jeweilige Abh¨ngigkeit wieder
                                             a
      Plan erfolgt “Top-Down”: Der oberste Planknoten ist der
      Einstiegspunkt
      Jeder Plan definiert Start-, Endkosten, gesch¨tzte Anzahl
                                                  a
      Zeilen und die Gr¨ße einer Ergebniszeile
                       o




         Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Pl¨ne lesen (2)
  a


  Jeder Planknoten enth¨lt:
                       a
      cost = Startkosten...Endkosten
      rows = Gesch¨tzte Anzahl Zeilen
                  a
      width = Durschn. Gr¨ße einer Zeile
                         o
  EXPLAIN ANALYZE f¨gt hinzu:
                   u
      actual time = Startzeit...Endzeit
      rows = Tats¨chliche Anzahl Zeilen
                 a
      loops = Wie oft wurde dieser Planknoten ausgef¨hrt
                                                    u
  Daneben gibt es weitere Angaben wie z.B. Trigger, Hauptspeicher
  usw.



          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Algorithmen im Detail - SeqScan
  Seq Scan (Sequential Table Scan):
  EXPLAIN SELECT t1.* FROM tenk1 t1 WHERE t1.unique2 > 100;

   Seq Scan on tenk1 t1 (cost=0.00..483.00 rows=9899 width=244)
     Filter: (unique2 > 100)




         Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Algorithmen im Detail - Nested Loop (1)


  EXPLAIN ANALYZE SELECT t1.* FROM tenk1 t1
                              JOIN tenk2 t2 ON (t1.unique1 = t2.unique1)
                              WHERE t2.unique2 > 100;

   Nested Loop  (cost=0.00..4795.00 rows=9899 width=244)
                (actual time=60.151..182.590 rows=9899 loops=1)
    ->   Seq Scan on tenk1 t1 (cost=0.00..458.00 rows=10000 width=244)
                               (actual time=0.010..8.628 rows=10000 loops=
    ->   Index Scan using tenk2_unique1 on tenk2 t2
         (cost=0.00..0.42 rows=1 width=4)
         (actual time=0.015..0.015 rows=1 loops=10000)
           Index Cond: (t2.unique1 = t1.unique1)
           Filter: (t2.unique2 > 100)




          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Algorithmen im Detail - Nested Loop (2)
    1               ¨
        “Outer” = Außere Tabelle, “Inner” = Innere Tabelle
    2   G¨nstigste Anordnung wird durch den Optimizer bestimmt
          u
    3   ¨
        Außere Schleife einmal, f¨r jede Zeile wird die Innere Schleife
                                 u
        jeweils durchsucht (Aufwand n * m)
    4   Durchsuchen der Tabellen anhand verschiedener Strategien
        (Indexscan, Seqscan usw.)




           Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Algorithmen im Detail - Merge Join (1)

  EXPLAIN ANALYZE SELECT t1.* FROM tenk1 t1
                                   JOIN tenk2 t2 ON (t1.unique1 = t2.unique1)
                                   WHERE t2.unique2 > 100;

   Merge Join  (cost=1126.95..3002.60 rows=9899 width=244)
               (actual time=48.168..124.313 rows=9899 loops=1)
     Merge Cond: (t1.unique1 = t2.unique1)
     -> Index Scan using tenk1_unique1 on tenk1 t1
         (cost=0.00..1702.17rows=10000 width=244)
         (actual time=20.425..67.893 rows=10000 loops=1)
     -> Sort (cost=1126.95..1151.70 rows=9899 width=4)
               (actual time=27.716..30.851 rows=9899 loops=1)
           Sort Key: t2.unique1
           Sort Method: quicksort Memory: 926kB
           -> Seq Scan on tenk2 t2
               (cost=0.00..470.00 rows=9899 width=4)
               (actual time=0.126..12.743 rows=9899 loops=1)
                 Filter: (unique2 > 100)




          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Algorithmen im Detail - Merge Join (2)
    1   Sortiere Tabelle tenk1, tenk2 anhand JoinKey
    2   Lese sortierte Keys tenk1, verkn¨pfe mit Keys tenk2
                                        u
    3   Ideal kombinierbar mit Indexscan
    4   Tabellen m¨ssen jeweils nur einmal gelesen werden,
                    u
        “Reißverschluß”




           Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Algorithmen im Detail - Hash Join (1)



  EXPLAIN ANALYZE SELECT t1.* FROM tenk1 t1
                              JOIN tenk2 t2 ON (t1.unique1 = t2.unique1)
                              WHERE t2.unique2 > 100;

   Hash Join  (cost=593.74..1300.73 rows=9899 width=244)
              (actual time=28.119..60.306 rows=9899 loops=1)
     Hash Cond: (t1.unique1 = t2.unique1)
     -> Seq Scan on tenk1 t1 (cost=0.00..458.00 rows=10000 width=244)
         (actual time=0.039..8.973 rows=10000 loops=1)
     -> Hash (cost=470.00..470.00 rows=9899 width=4)
               (actual time=27.641..27.641 rows=9899 loops=1)
           -> Seq Scan on tenk2 t2 (cost=0.00..470.00 rows=9899 width=4)
               (actual time=0.113..16.754 rows=9899 loops=1)
                 Filter: (unique2 > 100)




          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Algorithmen im Detail - Hash Join (2)
    1   Aufbauen einer Hashtabelle (aus tenk1 oder tenk2)
    2   Durchsuchen des Joinpartners und Vergleich auf Hashkey
    3   Komplett im RAM, f¨r gr¨ßere Datenmengen
                            u   o
    4   Teure Startup-Costs




           Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Algorithmen im Detail - Bitmap Index Scan (1)




  EXPLAIN ANALYZE SELECT * FROM tenk1 WHERE unique2 IN (2, 200, 234, -100, -203);

  Bitmap Heap Scan on tenk1 (cost=21.29..39.60 rows=5 width=244)
     (actual time=0.070..0.074 rows=3 loops=1)
     Recheck Cond: (unique2 = ANY (’{2,200,234,-100,-203}’::integer[]))
     -> Bitmap Index Scan on tenk1_unique2 (cost=0.00..21.29 rows=5 width=0)
         (actual time=0.062..0.062 rows=3 loops=1)
           Index Cond: (unique2 = ANY (’{2,200,234,-100,-203}’::integer[]))




          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Algorithmen im Detail - Bitmap Index Scan (2)
    1   Scanne Index, erzeuge Bitmap mit Treffern (Blocknummern)
    2   Sortiere Bitmap (Blocknummern aufsteigend)
    3   Scanne Tabelle anhand der Blocknummern der Bitmap
        aufsteigend
    4   “Lossy” Bitmap (Pages statt Tuple)




           Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Algorithmen im Detail - Index Scan (1)




  EXPLAIN ANALYZE SELECT * FROM tenk1 t2 WHERE unique2 = 100;

   Index Scan using tenk1_unique2 on tenk1 t2 (cost=0.00..8.27 rows=1 width=244)
     (actual time=0.022..0.023 rows=1 loops=1)
     Index Cond: (unique2 = 100)




          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Algorithmen im Detail - Index Scan (2)
    1   Indexscan erfordert Sichtbarkeitspr¨fung auf Tabelle pro
                                           u
        Indexfetch
    2   Dadurch relativ teuer
    3   F¨r kleine Treffermengen geeignet
          u




           Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Join Removal

  Optimierungsstrategie um ”nutzlose” Tabelle in einem LEFT
  JOIN zu eliminieren
      Nur rechte Seite eines LEFT JOINS
      Keine Tupel der Tabelle in der Ergebnismenge
      Rechte Seite eindeutig (erfordert UNIQUE Constraint)

  SELECT a.name
  FROM a LEFT JOIN b ON (a.id = b.id)
  WHERE a.name LIKE ’%foo%’;

   Seq Scan on a
     Filter: (name ~~ ’%foo%’::text)

  Siehe auch http://blog.credativ.com/de/2010/03/
  postgresql-optimizer-bits-join-removal.html

          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Semi-/Anti Joins




     Optimierungsstrategie f¨r EXISTS()/NOT EXISTS()
                            u
     Ber¨cksichtigt Schl¨ssel nur, sobald diese in der verkn¨pften
        u                u                                  u
     Tabelle auftreten (semi) oder nicht (anti)
     Erlaubt das Abarbeiten als impliziter JOIN
  Siehe auch http://blog.credativ.com/de/2010/02/
  postgresql-optimizer-bits-semi-und-anti-joins.html




        Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Semi-/Anti Joins - Beispiel


  SELECT id FROM a WHERE a.id = 200
         AND EXISTS(SELECT id FROM b WHERE a.id2 = b.id);

  8.4:
   Nested Loop Semi Join (cost=0.00..50.18 rows=6 width=4)
     -> Seq Scan on a (cost=0.00..24.50 rows=6 width=8)
           Filter: (id = 200)
     -> Index Scan using b_id_idx on b (cost=0.00..4.27 rows=1 width=4)
           Index Cond: (id = a.id2)
  8.3:
   Seq Scan on a (cost=0.00..9614.85 rows=3 width=4)
     Filter: ((id = 200) AND (subplan))
     SubPlan
       -> Index Scan using b_id_idx on b (cost=0.00..8.27 rows=1 width=4
             Index Cond: ($0 = id)



          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
SQL Inlining (1)


  Unter bestimmten Umst¨nden ist der Optimizer in der Lage,
                         a
  SQL-Funktionen zu ”inlinen”
       Geht nur mit reinen SQL-Funktionen
       ”Einfacher” SQL-Ausdruck
       Keine Seiteneffekte (VOLATILE)
       Darf nicht als STRICT deklariert sein
       SQL-Ausdruck darf Resultmenge nicht ver¨ndern
                                              a
       SECURITY DEFINER nicht erlaubt
  Beispiel...




           Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
SQL Inlining (2)
  CREATE TABLE test
     AS SELECT a FROM generate_series(1, 10000) AS t(a);
  CREATE INDEX test_id_idx ON test(a);

  CREATE FUNCTION test_f()
  RETURNS SETOF test VOLATILE LANGUAGE SQL
  AS $$ SELECT * FROM test; $$;

  EXPLAIN SELECT * FROM test_f() WHERE a = 100;

   Function Scan on test_f              (cost=0.25..12.75 rows=5 width=4)
     Filter: (a = 100)

  ALTER FUNCTION test_f() STABLE;

  EXPLAIN SELECT * FROM test_f() WHERE a = 100;

   Index Scan using test_id_idx on test                   (cost=0.00..8.29 rows=2 width=4)
     Index Cond: (a = 100)

          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Auto-Explain (1)




  Ab PostgreSQL 8.4
      Schreibt Ausf¨hrungspl¨ne in der PostgreSQL-Log
                   u        a
      Umfangreich konfigurierbar
      Erlaubt das Protokollieren von Pl¨nen innerhalb von
                                       a
      Prozeduren




         Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
Auto-Explain (2)




  $ cd <SOURCE>/contrib/auto_explain;
  $ make install
  $ psql dbname

  #= LOAD ’auto_explain’;
  #= SET auto_explain.log_min_duration = ’1ms’;
  #= SET auto_explain.log_nested_statements TO on;




        Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer
close()




                                    PQfinish(lecture);




          Bernd Helmle, bernd.helmle@credativ.de   Eine Reise durch den PostgreSQL Optimizer

Weitere ähnliche Inhalte

Andere mochten auch

Pelan Pemasaran
Pelan PemasaranPelan Pemasaran
Pelan Pemasaran
Nurhasbullah Ariffin
 
Я славлю край Донской. Евграфова Л. П. МБОУ Стычновская СОШ
Я славлю край Донской. Евграфова Л. П. МБОУ Стычновская СОШЯ славлю край Донской. Евграфова Л. П. МБОУ Стычновская СОШ
Я славлю край Донской. Евграфова Л. П. МБОУ Стычновская СОШ
Алексей Арешев
 
Презентация Осенние фантазии Л.П.Евграфова
Презентация Осенние фантазии Л.П.ЕвграфоваПрезентация Осенние фантазии Л.П.Евграфова
Презентация Осенние фантазии Л.П.Евграфова
Алексей Арешев
 
Liquidos y electrolitos
Liquidos y electrolitos Liquidos y electrolitos
Liquidos y electrolitos
eddynoy velasquez
 
Отчет об исполнении бюджета за 1 полугодие 2015 года
Отчет об исполнении бюджета за 1 полугодие 2015 годаОтчет об исполнении бюджета за 1 полугодие 2015 года
Отчет об исполнении бюджета за 1 полугодие 2015 года
Алексей Арешев
 
PROVISIONAL CERTIFICATE
PROVISIONAL CERTIFICATEPROVISIONAL CERTIFICATE
PROVISIONAL CERTIFICATEManoj Kumar
 
Tesis doctoral. informe.final.23.06.2010
Tesis doctoral. informe.final.23.06.2010Tesis doctoral. informe.final.23.06.2010
Tesis doctoral. informe.final.23.06.2010
Segundo Bueno
 
Liquidos y-electrolitos-en-la-niñezz
Liquidos y-electrolitos-en-la-niñezzLiquidos y-electrolitos-en-la-niñezz
Liquidos y-electrolitos-en-la-niñezz
Jareis wilson
 
Preparación de un proyecto para crowdfunding
Preparación de un proyecto para crowdfundingPreparación de un proyecto para crowdfunding
Preparación de un proyecto para crowdfunding
Xose Ramil
 
English for specific purpose : Approach Not Product
English for specific purpose : Approach Not ProductEnglish for specific purpose : Approach Not Product
English for specific purpose : Approach Not Product
Yulia Eolia
 
Story Grammar
Story GrammarStory Grammar
Story Grammar
David Widener
 
0.RESUME
0.RESUME0.RESUME

Andere mochten auch (12)

Pelan Pemasaran
Pelan PemasaranPelan Pemasaran
Pelan Pemasaran
 
Я славлю край Донской. Евграфова Л. П. МБОУ Стычновская СОШ
Я славлю край Донской. Евграфова Л. П. МБОУ Стычновская СОШЯ славлю край Донской. Евграфова Л. П. МБОУ Стычновская СОШ
Я славлю край Донской. Евграфова Л. П. МБОУ Стычновская СОШ
 
Презентация Осенние фантазии Л.П.Евграфова
Презентация Осенние фантазии Л.П.ЕвграфоваПрезентация Осенние фантазии Л.П.Евграфова
Презентация Осенние фантазии Л.П.Евграфова
 
Liquidos y electrolitos
Liquidos y electrolitos Liquidos y electrolitos
Liquidos y electrolitos
 
Отчет об исполнении бюджета за 1 полугодие 2015 года
Отчет об исполнении бюджета за 1 полугодие 2015 годаОтчет об исполнении бюджета за 1 полугодие 2015 года
Отчет об исполнении бюджета за 1 полугодие 2015 года
 
PROVISIONAL CERTIFICATE
PROVISIONAL CERTIFICATEPROVISIONAL CERTIFICATE
PROVISIONAL CERTIFICATE
 
Tesis doctoral. informe.final.23.06.2010
Tesis doctoral. informe.final.23.06.2010Tesis doctoral. informe.final.23.06.2010
Tesis doctoral. informe.final.23.06.2010
 
Liquidos y-electrolitos-en-la-niñezz
Liquidos y-electrolitos-en-la-niñezzLiquidos y-electrolitos-en-la-niñezz
Liquidos y-electrolitos-en-la-niñezz
 
Preparación de un proyecto para crowdfunding
Preparación de un proyecto para crowdfundingPreparación de un proyecto para crowdfunding
Preparación de un proyecto para crowdfunding
 
English for specific purpose : Approach Not Product
English for specific purpose : Approach Not ProductEnglish for specific purpose : Approach Not Product
English for specific purpose : Approach Not Product
 
Story Grammar
Story GrammarStory Grammar
Story Grammar
 
0.RESUME
0.RESUME0.RESUME
0.RESUME
 

Ähnlich wie Eine Reise durch den PostgreSQL Optimizer

Explain explain
Explain explainExplain explain
Explain explain
Hans-Jürgen Schönig
 
Java Streams und Lambdas
Java Streams und LambdasJava Streams und Lambdas
Java Streams und Lambdas
Nane Kratzke
 
Differenzial Analyse in der Praxis (Florian Walther)
Differenzial Analyse in der Praxis (Florian Walther)Differenzial Analyse in der Praxis (Florian Walther)
Differenzial Analyse in der Praxis (Florian Walther)GEEKcon
 
Inter Prozedurale Zeigeranalyse
Inter Prozedurale ZeigeranalyseInter Prozedurale Zeigeranalyse
Inter Prozedurale ZeigeranalyseTim Furche
 
nagiosplugin - eine Python-Biblioth­ek für Monitoring-Plug­ins
nagiosplugin - eine Python-Biblioth­ek für Monitoring-Plug­ins nagiosplugin - eine Python-Biblioth­ek für Monitoring-Plug­ins
nagiosplugin - eine Python-Biblioth­ek für Monitoring-Plug­ins
Christian Kauhaus
 
PostgreSQL: Eigene Aggregate schreiben
PostgreSQL: Eigene Aggregate schreibenPostgreSQL: Eigene Aggregate schreiben
PostgreSQL: Eigene Aggregate schreiben
Hans-Jürgen Schönig
 
Basisinformationstechnologie I WiSem 2015 / 2016 | 06_Rechnertechnologie II: ...
Basisinformationstechnologie I WiSem 2015 / 2016 | 06_Rechnertechnologie II: ...Basisinformationstechnologie I WiSem 2015 / 2016 | 06_Rechnertechnologie II: ...
Basisinformationstechnologie I WiSem 2015 / 2016 | 06_Rechnertechnologie II: ...
Institute for Digital Humanities, University of Cologne
 
Funktionale Programmierung und mehr mit Scala
Funktionale Programmierung und mehr mit ScalaFunktionale Programmierung und mehr mit Scala
Funktionale Programmierung und mehr mit Scala
thoherr
 
BIT I WiSe 2014 | Basisinformationstechnologie I - 04: Rechnertechnologie I
BIT I WiSe 2014 | Basisinformationstechnologie I - 04: Rechnertechnologie IBIT I WiSe 2014 | Basisinformationstechnologie I - 04: Rechnertechnologie I
BIT I WiSe 2014 | Basisinformationstechnologie I - 04: Rechnertechnologie I
Institute for Digital Humanities, University of Cologne
 
BIT I WiSe 2014 | Basisinformationstechnologie I - 08: Programmiersprachen I
BIT I WiSe 2014 | Basisinformationstechnologie I - 08: Programmiersprachen IBIT I WiSe 2014 | Basisinformationstechnologie I - 08: Programmiersprachen I
BIT I WiSe 2014 | Basisinformationstechnologie I - 08: Programmiersprachen I
Institute for Digital Humanities, University of Cologne
 
Markus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestalten
Markus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestaltenMarkus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestalten
Markus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestalten
Informatik Aktuell
 
Multithreaded Algorithms
Multithreaded Algorithms Multithreaded Algorithms
Multithreaded Algorithms
Kersten Broich
 
FH Wedel - SS11 - Seminar - Marcus Riemer - LEDA
FH Wedel - SS11 - Seminar - Marcus Riemer - LEDAFH Wedel - SS11 - Seminar - Marcus Riemer - LEDA
FH Wedel - SS11 - Seminar - Marcus Riemer - LEDA
Marcus Riemer
 
C++11 und c++14
C++11 und c++14C++11 und c++14
C++11 und c++14
Holger Jakobs
 
Go - Googles Sprache für skalierbare Systeme
Go - Googles Sprache für skalierbare SystemeGo - Googles Sprache für skalierbare Systeme
Go - Googles Sprache für skalierbare Systeme
Frank Müller
 
OOP 2013: Praktische Einführung in MongoDB
OOP 2013: Praktische Einführung in MongoDBOOP 2013: Praktische Einführung in MongoDB
OOP 2013: Praktische Einführung in MongoDB
Tobias Trelle
 
Spark vs. PL/SQL
Spark vs. PL/SQLSpark vs. PL/SQL
Schulung: Einführung in das GPU-Computing mit NVIDIA CUDA
Schulung: Einführung in das GPU-Computing mit NVIDIA CUDASchulung: Einführung in das GPU-Computing mit NVIDIA CUDA
Schulung: Einführung in das GPU-Computing mit NVIDIA CUDA
Jörn Dinkla
 
The Hadoop Connection
The Hadoop ConnectionThe Hadoop Connection
The Hadoop Connectioninovex GmbH
 

Ähnlich wie Eine Reise durch den PostgreSQL Optimizer (20)

Explain explain
Explain explainExplain explain
Explain explain
 
Java Streams und Lambdas
Java Streams und LambdasJava Streams und Lambdas
Java Streams und Lambdas
 
Differenzial Analyse in der Praxis (Florian Walther)
Differenzial Analyse in der Praxis (Florian Walther)Differenzial Analyse in der Praxis (Florian Walther)
Differenzial Analyse in der Praxis (Florian Walther)
 
Inter Prozedurale Zeigeranalyse
Inter Prozedurale ZeigeranalyseInter Prozedurale Zeigeranalyse
Inter Prozedurale Zeigeranalyse
 
nagiosplugin - eine Python-Biblioth­ek für Monitoring-Plug­ins
nagiosplugin - eine Python-Biblioth­ek für Monitoring-Plug­ins nagiosplugin - eine Python-Biblioth­ek für Monitoring-Plug­ins
nagiosplugin - eine Python-Biblioth­ek für Monitoring-Plug­ins
 
PostgreSQL: Eigene Aggregate schreiben
PostgreSQL: Eigene Aggregate schreibenPostgreSQL: Eigene Aggregate schreiben
PostgreSQL: Eigene Aggregate schreiben
 
Basisinformationstechnologie I WiSem 2015 / 2016 | 06_Rechnertechnologie II: ...
Basisinformationstechnologie I WiSem 2015 / 2016 | 06_Rechnertechnologie II: ...Basisinformationstechnologie I WiSem 2015 / 2016 | 06_Rechnertechnologie II: ...
Basisinformationstechnologie I WiSem 2015 / 2016 | 06_Rechnertechnologie II: ...
 
Funktionale Programmierung und mehr mit Scala
Funktionale Programmierung und mehr mit ScalaFunktionale Programmierung und mehr mit Scala
Funktionale Programmierung und mehr mit Scala
 
BIT I WiSe 2014 | Basisinformationstechnologie I - 04: Rechnertechnologie I
BIT I WiSe 2014 | Basisinformationstechnologie I - 04: Rechnertechnologie IBIT I WiSe 2014 | Basisinformationstechnologie I - 04: Rechnertechnologie I
BIT I WiSe 2014 | Basisinformationstechnologie I - 04: Rechnertechnologie I
 
BIT I WiSe 2014 | Basisinformationstechnologie I - 08: Programmiersprachen I
BIT I WiSe 2014 | Basisinformationstechnologie I - 08: Programmiersprachen IBIT I WiSe 2014 | Basisinformationstechnologie I - 08: Programmiersprachen I
BIT I WiSe 2014 | Basisinformationstechnologie I - 08: Programmiersprachen I
 
Markus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestalten
Markus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestaltenMarkus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestalten
Markus Winand – IT-Tage 2015 – Den Suchraum des Optimizers gestalten
 
Multithreaded Algorithms
Multithreaded Algorithms Multithreaded Algorithms
Multithreaded Algorithms
 
[10] Nup 07 4
[10] Nup 07 4[10] Nup 07 4
[10] Nup 07 4
 
FH Wedel - SS11 - Seminar - Marcus Riemer - LEDA
FH Wedel - SS11 - Seminar - Marcus Riemer - LEDAFH Wedel - SS11 - Seminar - Marcus Riemer - LEDA
FH Wedel - SS11 - Seminar - Marcus Riemer - LEDA
 
C++11 und c++14
C++11 und c++14C++11 und c++14
C++11 und c++14
 
Go - Googles Sprache für skalierbare Systeme
Go - Googles Sprache für skalierbare SystemeGo - Googles Sprache für skalierbare Systeme
Go - Googles Sprache für skalierbare Systeme
 
OOP 2013: Praktische Einführung in MongoDB
OOP 2013: Praktische Einführung in MongoDBOOP 2013: Praktische Einführung in MongoDB
OOP 2013: Praktische Einführung in MongoDB
 
Spark vs. PL/SQL
Spark vs. PL/SQLSpark vs. PL/SQL
Spark vs. PL/SQL
 
Schulung: Einführung in das GPU-Computing mit NVIDIA CUDA
Schulung: Einführung in das GPU-Computing mit NVIDIA CUDASchulung: Einführung in das GPU-Computing mit NVIDIA CUDA
Schulung: Einführung in das GPU-Computing mit NVIDIA CUDA
 
The Hadoop Connection
The Hadoop ConnectionThe Hadoop Connection
The Hadoop Connection
 

Eine Reise durch den PostgreSQL Optimizer

  • 1. Eine Reise durch den PostgreSQL Optimizer Bernd Helmle, bernd.helmle@credativ.de 23. August 2010 Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 2. Am Anfang steht SQL SQL = Structured Query Language Eigentlich ein Eigenname Standardisiert, stetige Weiterentwicklung (SQL99, SQL 2003, SQL 2008, SQL/MED) Deklarativ, Beschreibend KEIN(!) Programmcode Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 3. Optimizer? Planer? “Finde einen m¨glichst effizienten Weg um das gew¨nschte o u Resultat korrekt zu liefern” Optimizer ein wenig missverst¨ndlich a Planen und “optimieren” Liefert Arbeitsanweisungen f¨r den Executor u Fasst diese in einen m¨glichst effizienten “Plan” zusammen o Kritischer Faktor: Aufwand um m¨gliche Arbeitsschritte zu o einem guten Plan zu kombinieren Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 4. Was passiert im Datenbankserver? Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 5. Der Planer (1) Planer erh¨lt Query aus dem Rewriter a Drei Phasen: 1 Preprocessing Phase (Subqueries, Aggregates, WHERE-clauses) 2 Ermitteln der JOIN-Zugriffspfade (Pfad) 3 Zusammenfassen der Planknoten, Ausgabe als Plan Ein Plan ist das Ergebnis der m¨glichst g¨nstigsten o u Kombination der einzelnen Zugriffspfade (Nodes) Ggf. rekursive Aufrufe des Planers (Subqueries, SubPlan) Unterschiedliche Methoden f¨r Phase zwei. u Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 6. Der Planer (3) Exhaustive Search SELECT * FROM a, b, c, d WHERE a.col = b.col AND a.col = c.col AND a.col = d.col; {a,b} {a,c} {a,d} ... -> {a,b,c} {d} -> {d} {a,b,c} -> {a,b} {c,d} ... Ann¨hrend ”Ersch¨pfend” a o from collapse limit: Umschreiben von Subqueries in JOIN-Liste (Flattening) join collapse limit: Umsortieren von expliziten JOINs Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 7. Der Planer (4) GEQO (Genetic Query Optimizer) Semi-Randomisierte Suche ¨ Non-deterministische Auswahl (Anderungen in 9.0) Gute Gene (Planknoten) werden rekombiniert . . . die fittesten “Gene” gewinnen Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 8. Wie macht der Planer das? Heranziehen vermuteter Ergebniszeilen (pg class.reltuples) Ggf. interpolieren auf Anzahl aktueller phyiskalischer Bl¨cke o (pg class.relpages) Kosten f¨r Planknoten (bspw. Selektivit¨t f¨r Indexscan usw.) u a u . . . und nimmt den billigsten“. ” Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 9. Wie weiß der Planer das? Statistiken, von ANALYZE gesammelt Tabellenspezifische Kosten (pg class.reltuples, pg class.relpages Spaltenstatistiken (pg statistic, pg stats) Verstellbare Kostenparameter Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 10. Kostenparameter 1 seq page cost: I/O-Kosten f¨r einen sequentiellen u Block-Lesevorgang 2 random page cost: I/O-Kosten f¨r einen zuf¨lligen u a Block-Lesevorgang 3 effective cache size: Beeinflusst angenomme Cachegr¨ße o und damit Auswahl von Indexscans 4 cpu tuple cost: CPU-Kosten f¨r das Verarbeiten einer Zeile u einer Tabelle 5 cpu index tuple cost: CPU-Kosten f¨r das Verarbeiten u einer Zeile eines Indexes. 6 cpu operator cost: Operator- und/oder Prozedurkosten einer CPU. 7 cpu tuple fraction: Anteil des ersten Tupel aus einem Cursor Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 11. Kostenberechnung (1) Die Kostenfaktoren beeinflussen die Kostenberechnung. F¨r einen u Sequential Scan erfolgt diese beispielhaft wie folgt: Endkosten = (Anzahl Bl¨cke * seq_page_cost) o + (Anzahl Tupel * cpu_tuple_cost) Startkosten sind 0.00, da keine Maßnahmen f¨r das Erzeugen des u Planknotens n¨tig sind. o Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 12. Kostenberechnung (2) Neben diesem (einfachen) I/O-Kostenmodell verf¨gt der Planer u uber weitere, tiefgreifende Statistiken ¨ pg stats enth¨lt mittels ANALYZE ermittelte Statistiken pro a Tabelle und zugeh¨render Spalte o null fraq: Anteil NULL-Werte avg width: Durchschnittliche Gr¨ße in Bytes o n distinct: Unterschiedliche Werte einer Spalte most common vals: H¨ufigste Werte a most common freqs: Selektivit¨t der h¨ufigsten Werte a a histogram bounds: Gruppierung der Spaltenwerte in ungef¨hr gleich große Gruppen a correlation: Verteilung der Daten auf der Platte Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 13. Kostenberechnung (3) SELECT * FROM pg_stats WHERE tablename = ’tenk1’ AND attname = ’hundred’; -[ RECORD 1 ]-----+------------------------------------------ schemaname | public tablename | tenk1 attname | hundred null_frac | 0 avg_width | 4 n_distinct | 100 most_common_vals | {41,26,64,97} most_common_freqs | {0.0136667,0.0133333,0.0133333,0.0126667} histogram_bounds | {0,10,19,30,39,50,60,70,79,89,99} correlation | 0.0156366 Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 14. Pl¨ne lesen (1) a Plan besteht aus Planknoten: jeweils eine in sich abgeschlossene Arbeitseinheit Die Schachtelung gibt die jeweilige Abh¨ngigkeit wieder a Plan erfolgt “Top-Down”: Der oberste Planknoten ist der Einstiegspunkt Jeder Plan definiert Start-, Endkosten, gesch¨tzte Anzahl a Zeilen und die Gr¨ße einer Ergebniszeile o Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 15. Pl¨ne lesen (2) a Jeder Planknoten enth¨lt: a cost = Startkosten...Endkosten rows = Gesch¨tzte Anzahl Zeilen a width = Durschn. Gr¨ße einer Zeile o EXPLAIN ANALYZE f¨gt hinzu: u actual time = Startzeit...Endzeit rows = Tats¨chliche Anzahl Zeilen a loops = Wie oft wurde dieser Planknoten ausgef¨hrt u Daneben gibt es weitere Angaben wie z.B. Trigger, Hauptspeicher usw. Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 16. Algorithmen im Detail - SeqScan Seq Scan (Sequential Table Scan): EXPLAIN SELECT t1.* FROM tenk1 t1 WHERE t1.unique2 > 100; Seq Scan on tenk1 t1 (cost=0.00..483.00 rows=9899 width=244) Filter: (unique2 > 100) Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 17. Algorithmen im Detail - Nested Loop (1) EXPLAIN ANALYZE SELECT t1.* FROM tenk1 t1 JOIN tenk2 t2 ON (t1.unique1 = t2.unique1) WHERE t2.unique2 > 100; Nested Loop (cost=0.00..4795.00 rows=9899 width=244) (actual time=60.151..182.590 rows=9899 loops=1) -> Seq Scan on tenk1 t1 (cost=0.00..458.00 rows=10000 width=244) (actual time=0.010..8.628 rows=10000 loops= -> Index Scan using tenk2_unique1 on tenk2 t2 (cost=0.00..0.42 rows=1 width=4) (actual time=0.015..0.015 rows=1 loops=10000) Index Cond: (t2.unique1 = t1.unique1) Filter: (t2.unique2 > 100) Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 18. Algorithmen im Detail - Nested Loop (2) 1 ¨ “Outer” = Außere Tabelle, “Inner” = Innere Tabelle 2 G¨nstigste Anordnung wird durch den Optimizer bestimmt u 3 ¨ Außere Schleife einmal, f¨r jede Zeile wird die Innere Schleife u jeweils durchsucht (Aufwand n * m) 4 Durchsuchen der Tabellen anhand verschiedener Strategien (Indexscan, Seqscan usw.) Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 19. Algorithmen im Detail - Merge Join (1) EXPLAIN ANALYZE SELECT t1.* FROM tenk1 t1 JOIN tenk2 t2 ON (t1.unique1 = t2.unique1) WHERE t2.unique2 > 100; Merge Join (cost=1126.95..3002.60 rows=9899 width=244) (actual time=48.168..124.313 rows=9899 loops=1) Merge Cond: (t1.unique1 = t2.unique1) -> Index Scan using tenk1_unique1 on tenk1 t1 (cost=0.00..1702.17rows=10000 width=244) (actual time=20.425..67.893 rows=10000 loops=1) -> Sort (cost=1126.95..1151.70 rows=9899 width=4) (actual time=27.716..30.851 rows=9899 loops=1) Sort Key: t2.unique1 Sort Method: quicksort Memory: 926kB -> Seq Scan on tenk2 t2 (cost=0.00..470.00 rows=9899 width=4) (actual time=0.126..12.743 rows=9899 loops=1) Filter: (unique2 > 100) Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 20. Algorithmen im Detail - Merge Join (2) 1 Sortiere Tabelle tenk1, tenk2 anhand JoinKey 2 Lese sortierte Keys tenk1, verkn¨pfe mit Keys tenk2 u 3 Ideal kombinierbar mit Indexscan 4 Tabellen m¨ssen jeweils nur einmal gelesen werden, u “Reißverschluß” Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 21. Algorithmen im Detail - Hash Join (1) EXPLAIN ANALYZE SELECT t1.* FROM tenk1 t1 JOIN tenk2 t2 ON (t1.unique1 = t2.unique1) WHERE t2.unique2 > 100; Hash Join (cost=593.74..1300.73 rows=9899 width=244) (actual time=28.119..60.306 rows=9899 loops=1) Hash Cond: (t1.unique1 = t2.unique1) -> Seq Scan on tenk1 t1 (cost=0.00..458.00 rows=10000 width=244) (actual time=0.039..8.973 rows=10000 loops=1) -> Hash (cost=470.00..470.00 rows=9899 width=4) (actual time=27.641..27.641 rows=9899 loops=1) -> Seq Scan on tenk2 t2 (cost=0.00..470.00 rows=9899 width=4) (actual time=0.113..16.754 rows=9899 loops=1) Filter: (unique2 > 100) Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 22. Algorithmen im Detail - Hash Join (2) 1 Aufbauen einer Hashtabelle (aus tenk1 oder tenk2) 2 Durchsuchen des Joinpartners und Vergleich auf Hashkey 3 Komplett im RAM, f¨r gr¨ßere Datenmengen u o 4 Teure Startup-Costs Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 23. Algorithmen im Detail - Bitmap Index Scan (1) EXPLAIN ANALYZE SELECT * FROM tenk1 WHERE unique2 IN (2, 200, 234, -100, -203); Bitmap Heap Scan on tenk1 (cost=21.29..39.60 rows=5 width=244) (actual time=0.070..0.074 rows=3 loops=1) Recheck Cond: (unique2 = ANY (’{2,200,234,-100,-203}’::integer[])) -> Bitmap Index Scan on tenk1_unique2 (cost=0.00..21.29 rows=5 width=0) (actual time=0.062..0.062 rows=3 loops=1) Index Cond: (unique2 = ANY (’{2,200,234,-100,-203}’::integer[])) Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 24. Algorithmen im Detail - Bitmap Index Scan (2) 1 Scanne Index, erzeuge Bitmap mit Treffern (Blocknummern) 2 Sortiere Bitmap (Blocknummern aufsteigend) 3 Scanne Tabelle anhand der Blocknummern der Bitmap aufsteigend 4 “Lossy” Bitmap (Pages statt Tuple) Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 25. Algorithmen im Detail - Index Scan (1) EXPLAIN ANALYZE SELECT * FROM tenk1 t2 WHERE unique2 = 100; Index Scan using tenk1_unique2 on tenk1 t2 (cost=0.00..8.27 rows=1 width=244) (actual time=0.022..0.023 rows=1 loops=1) Index Cond: (unique2 = 100) Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 26. Algorithmen im Detail - Index Scan (2) 1 Indexscan erfordert Sichtbarkeitspr¨fung auf Tabelle pro u Indexfetch 2 Dadurch relativ teuer 3 F¨r kleine Treffermengen geeignet u Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 27. Join Removal Optimierungsstrategie um ”nutzlose” Tabelle in einem LEFT JOIN zu eliminieren Nur rechte Seite eines LEFT JOINS Keine Tupel der Tabelle in der Ergebnismenge Rechte Seite eindeutig (erfordert UNIQUE Constraint) SELECT a.name FROM a LEFT JOIN b ON (a.id = b.id) WHERE a.name LIKE ’%foo%’; Seq Scan on a Filter: (name ~~ ’%foo%’::text) Siehe auch http://blog.credativ.com/de/2010/03/ postgresql-optimizer-bits-join-removal.html Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 28. Semi-/Anti Joins Optimierungsstrategie f¨r EXISTS()/NOT EXISTS() u Ber¨cksichtigt Schl¨ssel nur, sobald diese in der verkn¨pften u u u Tabelle auftreten (semi) oder nicht (anti) Erlaubt das Abarbeiten als impliziter JOIN Siehe auch http://blog.credativ.com/de/2010/02/ postgresql-optimizer-bits-semi-und-anti-joins.html Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 29. Semi-/Anti Joins - Beispiel SELECT id FROM a WHERE a.id = 200 AND EXISTS(SELECT id FROM b WHERE a.id2 = b.id); 8.4: Nested Loop Semi Join (cost=0.00..50.18 rows=6 width=4) -> Seq Scan on a (cost=0.00..24.50 rows=6 width=8) Filter: (id = 200) -> Index Scan using b_id_idx on b (cost=0.00..4.27 rows=1 width=4) Index Cond: (id = a.id2) 8.3: Seq Scan on a (cost=0.00..9614.85 rows=3 width=4) Filter: ((id = 200) AND (subplan)) SubPlan -> Index Scan using b_id_idx on b (cost=0.00..8.27 rows=1 width=4 Index Cond: ($0 = id) Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 30. SQL Inlining (1) Unter bestimmten Umst¨nden ist der Optimizer in der Lage, a SQL-Funktionen zu ”inlinen” Geht nur mit reinen SQL-Funktionen ”Einfacher” SQL-Ausdruck Keine Seiteneffekte (VOLATILE) Darf nicht als STRICT deklariert sein SQL-Ausdruck darf Resultmenge nicht ver¨ndern a SECURITY DEFINER nicht erlaubt Beispiel... Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 31. SQL Inlining (2) CREATE TABLE test AS SELECT a FROM generate_series(1, 10000) AS t(a); CREATE INDEX test_id_idx ON test(a); CREATE FUNCTION test_f() RETURNS SETOF test VOLATILE LANGUAGE SQL AS $$ SELECT * FROM test; $$; EXPLAIN SELECT * FROM test_f() WHERE a = 100; Function Scan on test_f (cost=0.25..12.75 rows=5 width=4) Filter: (a = 100) ALTER FUNCTION test_f() STABLE; EXPLAIN SELECT * FROM test_f() WHERE a = 100; Index Scan using test_id_idx on test (cost=0.00..8.29 rows=2 width=4) Index Cond: (a = 100) Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 32. Auto-Explain (1) Ab PostgreSQL 8.4 Schreibt Ausf¨hrungspl¨ne in der PostgreSQL-Log u a Umfangreich konfigurierbar Erlaubt das Protokollieren von Pl¨nen innerhalb von a Prozeduren Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 33. Auto-Explain (2) $ cd <SOURCE>/contrib/auto_explain; $ make install $ psql dbname #= LOAD ’auto_explain’; #= SET auto_explain.log_min_duration = ’1ms’; #= SET auto_explain.log_nested_statements TO on; Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer
  • 34. close() PQfinish(lecture); Bernd Helmle, bernd.helmle@credativ.de Eine Reise durch den PostgreSQL Optimizer