Het verschil in de uitvoeringstijd van de query is omdat de eerste uitvoering veel meer blokken van 8 kB van schijf moet lezen:vergelijk shared read=631496 en shared read=30359 .
PostgreSQL besluit de index niet te gebruiken voor de WHERE voorwaarde, maar de index die de ORDER BY . ondersteunt . Merk op dat vanwege de IN het is niet mogelijk om één index te gebruiken voor zowel de WHERE staat en de ORDER BY – dat kan alleen voor WHERE voorwaarden die gebruik maken van = als vergelijkingsoperator.
Dus PostgreSQL moet een keuze maken, en waarschijnlijk maakt het de verkeerde:aangezien de statistieken de optimizer vertellen dat er veel rijen zijn die voldoen aan de WHERE voorwaarde, besluit het de rijen in ORDER BY . te lezen bestel en gooi degenen weg die niet overeenkomen met de WHERE voorwaarde totdat het 100 resultaatrijen heeft gevonden. Helaas lijkt het erop dat de overeenkomende rijen niet dicht bij het begin van de tabel staan, en PostgreSQL moet veel rijen scannen (Rows Removed by Filter: 17276154 ).
Gebruik hiervoor een indexscan voor de WHERE staat, wijzigt u de ORDER BY clausule zodat PostgreSQL er geen index voor kan gebruiken:
ORDER BY datetime + INTERVAL '0 seconds' DESC
Aangezien er hier geen gebruik is voor een index met meerdere kolommen, zou de beste index zijn
CREATE INDEX ON report (sensor_id);