Ich habe die folgende Abfrage
%Vor%Es läuft furchtbar 110 Sekunden .
Die Tabellengrößen:
%Vor% Wenn ich jedoch den Parameter LIMIT von 50 auf 1000 ändere, endet die Abfrage in 2 Sekunden .
Hier ist der Abfrageplan für den langsamen
%Vor%und für den schnellen
%Vor%Offensichtlich sind die Ausführungspläne sehr unterschiedlich und die zweite führt zu einer Abfrage 50 mal schneller .
Ich habe Indizes für alle Felder, die an der Abfrage beteiligt sind, und ich habe ANALYZE in allen Tabellen ausgeführt, bevor die Abfragen ausgeführt wurden.
Kann jemand sehen, was mit der ersten Frage falsch ist?
UPDATE: Tabellendefinitionen
%Vor% %Vor% %Vor%UPDATE: Datenbankparameter
%Vor%Hier ist ein interessanter Teil der offiziellen ANALYZE Dokumentation.
Bei großen Tabellen verwendet ANALYZE eine Stichprobe des Tabelleninhalts, anstatt jede Zeile zu untersuchen. [...] Der Umfang der Analyse kann durch Anpassen der Konfigurationsvariable default_statistics_target oder durch Klicken auf Spalte für Spalte gesteuert werden, indem das Statistikziel für die Spalte mit ALTER TABLE ... ALTER COLUMN ... SET STATISTICS festgelegt wird.
Offenbar ist es eine übliche Methode, um fehlerhafte Abfragepläne zu verbessern. Analyse wird etwas langsamer sein, aber Abfrageplan kann besser sein.
Bei der ersten Abfrage verwendet der Optimierer stretegies, die die Sortierung über den Primärschlüsselscan umgehen. Das Problem ist, Ergebnisse treffen die Bedingung auf document.fk_id sind zu selten gegründet. Daher sollten index scan und nl join weit entfernt sein, um den Ergebnis-Bucket zu füllen.
Tags und Links sql postgresql sql-execution-plan query-optimization