Ich habe Ihren Abfrageplan auf explain.depesz.com gepostet, werfen Sie einen Blick darauf.
Die Schätzungen des Abfrageplaners sind an einigen Stellen furchtbar falsch. Haben Sie ANALYZE ausgeführt kürzlich?
Lesen Sie die Kapitel im Handbuch über vom Planer verwendete Statistiken und Kostenkonstanten des Planers. Achten Sie besonders auf die Kapitel zu random_page_cost und default_statistics_target .
Sie könnten Folgendes versuchen:
ALTER TABLE diplomas ALTER COLUMN number SET STATISTICS 1000;
ANALYZE diplomas;
Oder gehen Sie noch höher für eine Tabelle mit 10 Millionen Zeilen. Dies hängt von der Datenverteilung und den tatsächlichen Abfragen ab . Experiment. Standard ist 100, Maximum ist 10000.
Für eine Datenbank dieser Größe nur 1 oder 5 MB work_mem reichen in der Regel nicht aus. Lesen Sie die Postgres-Wiki-Seite zur Optimierung von Postgres, auf die @aleroot verlinkt ist.
Da Ihre Abfrage 430104 KB Speicherplatz auf der Festplatte benötigt gemäß EXPLAIN ausgegeben, müssen Sie work_mem setzen auf etwas wie 500 MB oder mehr, um eine In-Memory-Sortierung zu ermöglichen. Die In-Memory-Darstellung von Daten benötigt etwas mehr Platz als die On-Disk-Darstellung. Es könnte Sie interessieren, was Tom Lane kürzlich zu diesem Thema gepostet hat.
Erhöhen von work_mem um nur ein wenig, wie Sie es versucht haben, hilft nicht viel oder kann sogar verlangsamen. Global auf hoch zu setzen, kann sogar schaden, insbesondere bei gleichzeitigem Zugriff. Mehrere Sitzungen können sich gegenseitig nach Ressourcen hungern. Die Zuweisung von mehr für einen Zweck nimmt einem anderen Speicher weg, wenn die Ressource begrenzt ist. Das beste Setup hängt von der Gesamtsituation ab.
Um Nebeneffekte zu vermeiden, setzen Sie ihn nur lokal in Ihrer Sitzung hoch genug und vorübergehend für die Abfrage:
SET work_mem = '500MB';
Danach auf Standard zurücksetzen:
RESET work_mem;
Oder verwenden Sie SET LOCAL um es zunächst nur für die aktuelle Transaktion festzulegen.
