PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Postgresql join_collapse_limit und Zeit für die Abfrageplanung

Die neue Version 9.4 von PostgreSQL (zum Zeitpunkt des Schreibens dieses Artikels noch nicht veröffentlicht) wird EXPLAIN Planungszeit hinzufügen und EXPLAIN ANALYZE , und Sie können diese verwenden.

Für ältere Versionen ist Ihre Annahme richtig, der bessere Weg, die Planungszeit zu bestimmen, ist die Ausführung eines einfachen EXPLAIN (kein ANALYZE ) und die benötigte Zeit in psql überprüfen Sie können dies tun, indem Sie \timing aktivieren (Ich mache das normalerweise unter ~/.psqlrc ).

Das PostgreSQL-Hackerteam hat bereits darüber diskutiert, es auf größere Werte anzuheben . Aber es sieht so aus, als könnten sie nicht garantieren, dass es für alle Fälle gut wäre.

Das Problem ist die Planung, die beste Join-Reihenfolge für N zu finden tables akzeptiert ein O(N!) (faktorieller) Ansatz. Und so sind die Zahlen der Erhöhung sehr hoch, das können Sie einfach mit der folgenden Abfrage sehen:

$ SELECT i, (i)! AS num_comparisons FROM generate_series(8, 20) i;
 i  |   num_comparisons   
----+---------------------
  8 |               40320
  9 |              362880
 10 |             3628800
 11 |            39916800
 12 |           479001600
 13 |          6227020800
 14 |         87178291200
 15 |       1307674368000
 16 |      20922789888000
 17 |     355687428096000
 18 |    6402373705728000
 19 |  121645100408832000
 20 | 2432902008176640000
(13 rows)

Wie Sie sehen können, führen wir beim Standardwert von 8 höchstens etwa 40.000 Vergleiche durch, die von Ihnen vorgeschlagenen 10 führen zu 3M, was für moderne Computer immer noch nicht sehr viel ist, aber die nächsten Werte werden zu groß, sie steigen nur an zu schnell, die 20 ist einfach verrückt (21! passt nicht einmal zu einer 64-Bit-Ganzzahl).

Natürlich können Sie manchmal größere Werte wie 16 festlegen, die (theoretisch) bis zu 20 Billionen Vergleiche ermöglichen könnten, und dennoch eine sehr gute Planungszeit haben, da PostgreSQL beim Planen einige Pfade einschneidet und nicht benötigt zu immer Überprüfen Sie alle Bestellungen, aber davon auszugehen, dass dies immer der Fall sein wird, und so hohe Werte zum Standardwert zu machen, sieht für mich nicht nach einem guten Ansatz aus. Es kann in Zukunft eine unerwartete Abfrage geben, die dazu führt, dass alle Bestellungen überprüft werden, und dann haben Sie eine einzige Abfrage, die Ihren Server herunterfährt.

Nach meiner Erfahrung nehme ich die 10 als Standardwert bei jeder Installation in guten Servern an, einige davon verwende ich sogar 12. Ich empfehle Ihnen, sie auf 10 zu setzen, wenn Sie möchten, und manchmal versuchen Sie es höher ( Ich würde nicht über 12 hinausgehen und (genau) beobachten, um zu sehen, wie es sich verhält.