Även om det inte är lika användbart för en enkel plan som denna, är http://explain.depesz.com verkligen användbar. Se http://explain.depesz.com/s/t4fi. Notera fliken "statistik" och rullgardinsmenyn "alternativ".
Saker att notera om denna plan:
-
Det uppskattade radantalet (183) är rimligt jämförbart med det faktiska radantalet (25). Det är inte hundratals gånger mer, och det är inte heller 1. Du är mer intresserad av storleksordningar när det gäller uppskattningar av antal rader, eller "1 vs inte 1"-problem. (Du behöver inte ens "nära nog för statligt arbete" noggrannhet - "nära nog för militär entreprenadredovisning" duger). Selektivitetsuppskattningen och statistiken verkar rimliga.
-
Den använder det tvåkolumniga partiella index som tillhandahålls (
index scan using index_cars_onsale_on_brand_and_model_name), så det matchar det partiella indexvillkoret. Du kan se det iFilter: has_auto_gear. Indexsökningsvillkoret visas också. -
Frågeprestanda ser rimlig ut med tanke på att tabellens radantal kommer att innebära att indexet är ganska stort, särskilt som det är över två kolumner. Matchande rader kommer att vara spridda, så det är troligt att varje rad också kräver en separat sida som läses.
Jag ser inget fel här. Den här frågan kommer sannolikt att ha stor nytta av PostgreSQL 9.2:s index-endast skanningar.
Det är möjligt att det finns en tabelluppsvällning här, men med tanke på indexet med 2 kolumner och det stora antalet rader är svarstiden inte helt orimlig, särskilt för en tabell med 170 (!!) kolumner som sannolikt får plats med relativt få tuplar i varje kolumn. sida. Om du har råd med lite stillestånd, försök VACUUM FULL att omorganisera tabellen och bygga om indexet. Detta kommer exklusivt att låsa bordet under en tid medan det bygger om det. Om du inte har råd med stilleståndstiden, se pg_reorg och/eller CREATE INDEX CONCURRENTLY och ALTER INDEX ... RENAME TO .
Du kan hitta EXPLAIN (ANALYZE, BUFFERS, VERBOSE) mer informativ ibland, eftersom den kan visa buffertåtkomster, etc.
Ett alternativ som kan göra den här frågan snabbare (även om den riskerar att sakta ner andra frågor något) är att partitionera tabellen på brand och aktivera constraint_exclusion . Se partitionering.