Kostenparameter des Planers
Dies sagt mir, dass Ihre random_page_cost und seq_page_cost sind wohl falsch. Sie verwenden wahrscheinlich einen Speicher mit schnellen zufälligen E/A – entweder weil der Großteil der Datenbank im RAM zwischengespeichert ist oder weil Sie SSD, SAN mit Cache oder einen anderen Speicher verwenden, bei dem zufällige E/A von Natur aus schnell sind.
Versuchen Sie:
SET random_page_cost = 1;
SET seq_page_cost = 1.1;
um die Kostenparameterunterschiede stark zu reduzieren und dann erneut auszuführen. Wenn dies der Fall ist, ziehen Sie in Betracht, diese Parameter in postgresql.conf. zu ändern .
Ihre Zeilenanzahlschätzungen sind vernünftig, daher sieht es nicht nach einem Planer-Fehlschätzungsproblem oder einem Problem mit schlechten Tabellenstatistiken aus.
Falsche Abfrage
Deine Abfrage ist auch falsch. OFFSET 0 LIMIT 1 ohne ORDER BY führt zu unvorhersehbaren Ergebnissen, es sei denn, Sie haben garantiert genau eine Übereinstimmung, in diesem Fall OFFSET ... LIMIT ... Klauseln sind unnötig und können vollständig entfernt werden.
Normalerweise sind Sie besser dran, wenn Sie solche Abfragen wie SELECT max(...) formulieren oder SELECT min(...) wo möglich; PostgreSQL wird in der Regel in der Lage sein, einen Index zu verwenden, um den gewünschten Wert einfach abzugreifen, ohne einen teuren Tabellen-Scan oder einen Index-Scan und -Sortierung durchzuführen.
Tipps
Übrigens, für zukünftige Fragen hat das PostgreSQL-Wiki einige gute Informationen in der Leistungskategorie und eine Anleitung zum Stellen von Fragen zu langsamen Abfragen .
