Въпреки че не е толкова полезен за прост план като този, http://explain.depesz.com е наистина полезен. Вижте http://explain.depesz.com/s/t4fi. Обърнете внимание на раздела „статистика“ и падащото меню „опции“.
Неща, които трябва да отбележите относно този план:
-
Изчисленият брой редове (183) е разумно сравним с действителния брой редове (25). Не е стотици пъти повече, нито е 1. Вие сте по-заинтересовани от порядъка на величината, когато става въпрос за оценките на броя на редовете или проблемите „1 срещу не 1“. (Дори не се нуждаете от точност „достатъчно близо за държавна работа“ – „достатъчно близо за счетоводство на военни договори“ ще стане). Оценката на селективността и статистиката изглеждат разумни.
-
Използва предоставения частичен индекс с две колони (
index scan using index_cars_onsale_on_brand_and_model_name), така че съответства на условието за частичен индекс. Можете да видите това въвFilter: has_auto_gear. Показва се и условието за търсене в индекса. -
Ефективността на заявката изглежда разумна, като се има предвид, че броят на редовете в таблицата ще означава, че индексът е доста голям, особено след като е над две колони. Съвпадащите редове ще бъдат разпръснати, така че е вероятно всеки ред също да изисква четене на отделна страница.
Не виждам нищо лошо тук. Тази заявка вероятно ще се възползва много от сканирането само за индекси на PostgreSQL 9.2.
Възможно е тук да има някакво раздуване на таблицата, но като се има предвид индексът с 2 колони и големият брой редове, времето за отговор не е съвсем неразумно, особено за таблица със 170 (!!) колони, които вероятно ще поберат сравнително малко кортежи във всяка една таблица. страница. Ако можете да си позволите малко престой, опитайте VACUUM FULL за реорганизиране на таблицата и възстановяване на индекса. Това ще заключи изключително таблицата за известно време, докато я възстановява. Ако не можете да си позволите престой, вижте pg_reorg и/или CREATE INDEX CONCURRENTLY и ALTER INDEX ... RENAME TO .
Може да намерите EXPLAIN (ANALYZE, BUFFERS, VERBOSE) понякога по-информативен, тъй като може да показва достъп до буфер и т.н.
Една от опциите, която може да направи тази заявка по-бърза (въпреки че има риск да забави донякъде други заявки) е да разделите таблицата на brand и активирайте constraint_exclusion . Вижте разделяне.
