La différence de temps d'exécution de la requête est due au fait que la première exécution doit lire beaucoup plus de blocs de 8 Ko sur le disque :comparez shared read=631496 et shared read=30359 .
PostgreSQL décide de ne pas utiliser l'index pour le WHERE condition, mais l'index qui prend en charge le ORDER BY . Notez qu'à cause du IN il n'est pas possible d'utiliser un index pour les deux WHERE condition et le ORDER BY – cela n'est possible que pour WHERE conditions qui utilisent = comme opérateur de comparaison.
PostgreSQL doit donc faire un choix, et il fait probablement le mauvais choix :puisque ses statistiques indiquent à l'optimiseur qu'il existe de nombreuses lignes qui satisfont le WHERE condition, il décide de lire les lignes dans ORDER BY commandez et jetez ceux qui ne correspondent pas à WHERE condition jusqu'à ce qu'il ait trouvé 100 lignes de résultat. Malheureusement, il semble que les lignes correspondantes ne soient pas proches du début de la table, et PostgreSQL doit analyser de nombreuses lignes (Rows Removed by Filter: 17276154 ).
Pour le faire utiliser une analyse d'index pour le WHERE condition, modifiez le ORDER BY clause afin que PostgreSQL ne puisse pas utiliser d'index pour celle-ci :
ORDER BY datetime + INTERVAL '0 seconds' DESC
Puisqu'il n'y a aucune utilité pour un index multi-colonnes ici, le meilleur index serait
CREATE INDEX ON report (sensor_id);
