De oorzaak van de traagheid zijn de slechte schattingen van het aantal rijen waardoor PostgreSQL een geneste lus-join kiest. Bijna al uw tijd wordt besteed aan de indexscan op hfj_res_link , die 1113 keer wordt herhaald.
Mijn eerste poging zou zijn om ANALYZE hfj_spidx_date en kijken of dat helpt. Zo ja, zorg er dan voor dat autoanalyse die tabel vaker behandelt.
De volgende poging zou zijn om
SET default_statistics_target = 1000;
en dan ANALYZE zoals hierboven. Als dat helpt, gebruik dan ALTER TABLE om de STATISTICS . te verhogen op de hash_identity en sp_value_high kolommen.
Als dat ook niet helpt, en je hebt een recente versie van PostgreSQL, kun je uitgebreide statistieken proberen :
CREATE STATISTICS myparamsda2_stats (dependencies)
ON hash_identity, sp_value_high FROM hfj_spidx_date;
Dan ANALYZE de tafel opnieuw en kijk of dat helpt.
Als dat allemaal niet helpt en u de schattingen niet correct kunt krijgen, moet u een andere hoek proberen:
CREATE INDEX ON hfj_res_link (target_resource_id, src_resource_id);
Dat zou de indexscan aanzienlijk moeten versnellen en je goede responstijden moeten geven.
Ten slotte, als geen van de bovenstaande effecten enig effect heeft, kunt u de kruismaat gebruiken om geneste lus-joins voor deze query niet toe te staan:
BEGIN;
SET LOCAL enable_nestloop = off;
SELECT /* your query goes here */;
COMMIT;