Forskellen i forespørgsels eksekveringstid er, fordi den første udførelse skal læse langt flere 8kB blokke fra disken:sammenlign shared read=631496 og shared read=30359 .
PostgreSQL beslutter ikke at bruge indekset til WHERE betingelse, men indekset, der understøtter ORDER BY . Bemærk, at på grund af IN det er ikke muligt at bruge ét indeks for både WHERE betingelse og ORDER BY – det er kun muligt for WHERE betingelser, der bruger = som sammenligningsoperatør.
Så PostgreSQL er nødt til at træffe et valg, og det gør sandsynligvis det forkerte:da dets statistik fortæller optimeringsværktøjet, at der er mange rækker, der opfylder WHERE betingelse, beslutter den at læse rækkerne i ORDER BY bestil og kasser dem, der ikke matcher WHERE tilstand, indtil den har fundet 100 resultatrækker. Desværre ser det ud til, at de matchende rækker ikke er tæt på begyndelsen af tabellen, og PostgreSQL skal scanne mange rækker (Rows Removed by Filter: 17276154 ).
For at få det til at bruge en indeksscanning efter WHERE betingelse, skal du ændre ORDER BY klausul, så PostgreSQL ikke kan bruge et indeks til det:
ORDER BY datetime + INTERVAL '0 seconds' DESC
Da der ikke er brug for et indeks med flere kolonner her, ville det bedste indeks være
CREATE INDEX ON report (sensor_id);