Die Ursache für die Langsamkeit sind die schlechten Schätzungen der Zeilenanzahl, die dazu führen, dass PostgreSQL einen Nested-Loop-Join wählt. Fast Ihre gesamte Zeit verbringen Sie mit dem Indexscan auf hfj_res_link , die 1113 Mal wiederholt wird.
Mein erster Versuch wäre ANALYZE hfj_spidx_date und sehen, ob das hilft. Wenn ja, stellen Sie sicher, dass Autoanalyze diese Tabelle häufiger behandelt.
Der nächste Versuch wäre,
SET default_statistics_target = 1000;
und dann ANALYZE wie oben. Wenn das hilft, verwenden Sie ALTER TABLE um die STATISTICS zu erhöhen auf der hash_identity und sp_value_high Spalten.
Wenn das auch nicht hilft und Sie eine neuere Version von PostgreSQL haben, können Sie es mit erweiterten Statistiken versuchen :
CREATE STATISTICS myparamsda2_stats (dependencies)
ON hash_identity, sp_value_high FROM hfj_spidx_date;
Dann ANALYZE die Tabelle erneut und sehen Sie, ob das hilft.
Wenn das alles nicht hilft und Sie die Schätzungen nicht korrekt erhalten, müssen Sie einen anderen Blickwinkel versuchen:
CREATE INDEX ON hfj_res_link (target_resource_id, src_resource_id);
Das sollte den Index-Scan erheblich beschleunigen und Ihnen gute Antwortzeiten geben.
Wenn keiner der oben genannten Punkte eine Wirkung hat, könnten Sie schließlich die Cruse-Maßnahme anwenden, Nested-Loop-Joins für diese Abfrage zu verbieten:
BEGIN;
SET LOCAL enable_nestloop = off;
SELECT /* your query goes here */;
COMMIT;
