L'article concerne Postgres mais il est possible que ça puisse s'adapter à d'autres SGBD. Je cite l'auteur

Lorsqu’on identifie une requête lente, on remarque parfois qu’en forçant l’utilisation d’un index (avec enable_seqscan = off), le temps d’exécution est sensiblement réduit, parfois d’un facteur 100 ou 1000. Un DBA peut alors être tenté de jouer sur le paramètre random_page_cost pour favoriser l’utilisation de l’index. Mais celui-ci ne devrait dépendre que de la performance du stockage.
Dans un cas comme celui-là, il est vraiment nécessaire de s’attaquer à la cause première, qui est l’erreur d’estimation sur le nombre de lignes retournées. Parfois, le nom des colonnes donne un indice sur la façon dont elles sont corrélées, comme ici avec freqmin < freqmax, hypothèse qu’il est nécessaire de faire valider par le métier, pour ensuite en tirer profit, avec des statistiques étendues lorsque cela est possible, ou avec une ré-écriture de la requête.