La cause de la lenteur est la mauvaise estimation du nombre de lignes qui oblige PostgreSQL à choisir une jointure de boucle imbriquée. Presque tout votre temps est consacré à l'analyse de l'index sur hfj_res_link , qui est répété 1113 fois.
Ma première tentative serait de ANALYZE hfj_spidx_date et voir si cela aide. Si oui, assurez-vous que l'analyse automatique traite cette table plus fréquemment.
La prochaine tentative serait de
SET default_statistics_target = 1000;
puis ANALYZE comme ci-dessus. Si cela vous aide, utilisez ALTER TABLE pour augmenter les STATISTICS sur le hash_identity et sp_value_high colonnes.
Si cela ne vous aide pas non plus et que vous disposez d'une version récente de PostgreSQL, vous pouvez essayer les statistiques étendues :
CREATE STATISTICS myparamsda2_stats (dependencies)
ON hash_identity, sp_value_high FROM hfj_spidx_date;
Puis ANALYZE à nouveau le tableau et voyez si cela vous aide.
Si tout cela ne vous aide pas et que vous ne parvenez pas à obtenir les estimations correctes, vous devez essayer un angle différent :
CREATE INDEX ON hfj_res_link (target_resource_id, src_resource_id);
Cela devrait considérablement accélérer l'analyse de l'index et vous offrir de bons temps de réponse.
Enfin, si rien de ce qui précède n'a d'effet, vous pouvez utiliser la mesure crue consistant à interdire les jointures de boucles imbriquées pour cette requête :
BEGIN;
SET LOCAL enable_nestloop = off;
SELECT /* your query goes here */;
COMMIT;
