Hoewel niet zo handig voor een eenvoudig plan als dit, is http://explain.depesz.com erg handig. Zie http://explain.depesz.com/s/t4fi. Let op het tabblad "statistieken" en de vervolgkeuzelijst "opties".
Opmerkingen over dit plan:
-
Het geschatte aantal rijen (183) is redelijk vergelijkbaar met het werkelijke aantal rijen (25). Het is niet honderden keren meer, en ook niet 1. U bent meer geïnteresseerd in ordes van grootte als het gaat om schattingen van het aantal rijen, of '1 vs. niet 1'-kwesties. (Je hebt niet eens "dicht genoeg voor overheidswerk" nauwkeurigheid nodig - "dichtbij genoeg voor boekhouding van militaire contracten" is voldoende). De selectiviteitsschatting en statistieken lijken redelijk.
-
Het gebruikt de gedeeltelijke index met twee kolommen (
index scan using index_cars_onsale_on_brand_and_model_name), dus het komt overeen met de gedeeltelijke indexvoorwaarde. Je kunt dat zien in hetFilter: has_auto_gear. De zoekvoorwaarde voor de index wordt ook weergegeven. -
De queryprestaties zien er redelijk uit, aangezien het aantal rijen van de tabel betekent dat de index vrij groot is, vooral omdat deze uit meer dan twee kolommen bestaat. Overeenkomende rijen zullen verspreid zijn, dus het is waarschijnlijk dat voor elke rij ook een aparte pagina moet worden gelezen.
Ik zie hier niets mis. Deze zoekopdracht zal waarschijnlijk veel baat hebben bij PostgreSQL 9.2's alleen-index scans.
Het is mogelijk dat er hier wat opgeblazenheid in de tabel is, maar gezien de 2-kolomsindex en het enorme aantal rijen is de reactietijd niet helemaal onredelijk, vooral voor een tabel met 170 (!!) kolommen die waarschijnlijk relatief weinig tupels in elk zullen passen bladzijde. Als u zich wat downtime kunt veroorloven, probeer dan VACUUM FULL om de tabel te reorganiseren en de index opnieuw op te bouwen. Dit zal de tafel exclusief voor enige tijd vergrendelen terwijl deze opnieuw wordt opgebouwd. Als u zich de downtime niet kunt veroorloven, raadpleegt u pg_reorg en/of CREATE INDEX CONCURRENTLY en ALTER INDEX ... RENAME TO .
Mogelijk vindt u EXPLAIN (ANALYZE, BUFFERS, VERBOSE) soms informatiever, omdat het buffertoegangen, enz. kan tonen.
Een optie die deze zoekopdracht sneller kan maken (hoewel het risico bestaat dat andere zoekopdrachten enigszins worden vertraagd) is om de tabel te partitioneren op brand en schakel constraint_exclusion . in . Zie partitioneren.