La diferencia en el tiempo de ejecución de la consulta se debe a que la primera ejecución tiene que leer muchos más bloques de 8kB del disco:compare shared read=631496 y shared read=30359 .
PostgreSQL decide no usar el índice para WHERE condición, pero el índice que soporta el ORDER BY . Tenga en cuenta que debido a la IN no es posible usar un índice para ambos WHERE condición y el ORDER BY – eso solo es posible para WHERE condiciones que usan = como operador de comparación.
Entonces, PostgreSQL tiene que tomar una decisión, y probablemente tome la decisión equivocada:dado que sus estadísticas le dicen al optimizador que hay muchas filas que satisfacen WHERE condición, decide leer las filas en ORDER BY ordenar y descartar los que no coincidan con el WHERE condición hasta que haya encontrado 100 filas de resultados. Desafortunadamente, parece que las filas coincidentes no están cerca del comienzo de la tabla y PostgreSQL tiene que escanear muchas filas (Rows Removed by Filter: 17276154 ).
Para hacerlo, use un escaneo de índice para WHERE condición, modifique el ORDER BY cláusula para que PostgreSQL no pueda usar un índice para ello:
ORDER BY datetime + INTERVAL '0 seconds' DESC
Dado que aquí no se utiliza un índice de varias columnas, el mejor índice sería
CREATE INDEX ON report (sensor_id);
