Selvom det ikke er så nyttigt for en simpel plan som denne, er http://explain.depesz.com virkelig nyttig. Se http://explain.depesz.com/s/t4fi. Bemærk fanen "stats" og rullemenuen "indstillinger".
Ting at bemærke om denne plan:
-
Det estimerede rækkeantal (183) er rimeligt sammenligneligt med det faktiske rækkeantal (25). Det er ikke hundredvis af gange mere, og det er heller ikke 1. Du er mere interesseret i størrelsesordener, når det kommer til estimater for rækkeantal eller "1 vs ikke 1"-problemer. (Du behøver ikke engang "tæt nok til regeringsarbejde" nøjagtighed - "tæt nok til militær kontrahering regnskab" vil gøre). Selektivitetsestimatet og statistikken virker rimelige.
-
Den bruger det medfølgende delvise indeks med to kolonner (
index scan using index_cars_onsale_on_brand_and_model_name), så det matcher den delvise indeksbetingelse. Du kan se det iFilter: has_auto_gear. Indekssøgningsbetingelsen vises også. -
Forespørgselsydeevnen ser rimelig ud i betragtning af, at tabellens rækkeantal vil betyde, at indekset er ret stort, især da det er over to kolonner. Matchende rækker vil blive spredt, så det er sandsynligt, at hver række også kræver en separat sidelæsning.
Jeg ser intet galt her. Denne forespørgsel vil sandsynligvis have stor gavn af PostgreSQL 9.2's kun indekserede scanninger.
Det er muligt, at der er noget opsvulmet tabel her, men givet indekset med 2 kolonner og det store antal rækker, er responstiden ikke helt urimelig, især for en tabel med 170 (!!) kolonner, der sandsynligvis vil passe relativt få tuples ind i hver side. Hvis du har råd til noget nedetid, prøv VACUUM FULL at omorganisere tabellen og genopbygge indekset. Dette vil udelukkende låse bordet i nogen tid, mens det genopbygger det. Hvis du ikke har råd til nedetiden, se pg_reorg og/eller CREATE INDEX CONCURRENTLY og ALTER INDEX ... RENAME TO .
Du kan muligvis finde EXPLAIN (ANALYZE, BUFFERS, VERBOSE) nogle gange mere informativ, da den kan vise bufferadgange osv.
En mulighed, der kan gøre denne forespørgsel hurtigere (selvom den risikerer at bremse andre forespørgsler noget) er at partitionere tabellen på brand og aktiver constraint_exclusion . Se partitionering.