Chociaż nie jest tak przydatny w przypadku prostego planu, jak ten, http://explain.depesz.com jest naprawdę przydatny. Zobacz http://explain.depesz.com/s/t4fi. Zwróć uwagę na kartę „statystyki” i menu „opcje”.
Ważne informacje dotyczące tego planu:
-
Szacowana liczba wierszy (183) jest w miarę porównywalna z rzeczywistą liczbą wierszy (25). To nie jest setki razy więcej, ani nie jest to 1. Bardziej interesują Cię rzędy wielkości, jeśli chodzi o szacowanie liczby wierszy lub problemy „1 vs nie 1”. (Nie potrzebujesz nawet dokładności "wystarczająco blisko do pracy rządowej" - wystarczy "wystarczająco blisko do księgowości wojskowej"). Szacunki i statystyki selektywności wydają się rozsądne.
-
Używa podanego dwukolumnowego częściowego indeksu (
index scan using index_cars_onsale_on_brand_and_model_name
), więc jest zgodny z warunkiem częściowego indeksu. Możesz to zobaczyć wFilter: has_auto_gear
. Pokazany jest również warunek wyszukiwania indeksu. -
Wydajność zapytania wydaje się rozsądna, biorąc pod uwagę, że liczba wierszy w tabeli oznacza, że indeks jest dość duży, zwłaszcza że zawiera ponad dwie kolumny. Pasujące wiersze zostaną porozrzucane, więc prawdopodobnie każdy wiersz będzie również wymagał przeczytania osobnej strony.
Nie widzę tu nic złego. Zapytanie to prawdopodobnie bardzo skorzysta na skanowaniu PostgreSQL 9.2 tylko z indeksem.
Możliwe, że jest tu trochę rozdęcia tabeli, ale biorąc pod uwagę 2-kolumnowy indeks i samą liczbę wierszy, czas odpowiedzi nie jest całkowicie nierozsądny, szczególnie w przypadku tabeli ze 170 (!!) kolumnami, w której prawdopodobnie zmieści się stosunkowo niewiele krotek strona. Jeśli możesz sobie pozwolić na przestoje, spróbuj VACUUM FULL
aby zreorganizować tabelę i odbudować indeks. Spowoduje to zablokowanie tabeli na pewien czas podczas jej przebudowy. Jeśli nie możesz sobie pozwolić na przestój, zobacz pg_reorg i/lub CREATE INDEX CONCURRENTLY
i ALTER INDEX ... RENAME TO
.
Możesz znaleźć EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
czasami zawiera więcej informacji, ponieważ może pokazywać dostęp do bufora itp.
Jedną z opcji, która może przyspieszyć to zapytanie (chociaż wiąże się to z ryzykiem spowolnienia innych zapytań) jest partycjonowanie tabeli na brand
i włącz constraint_exclusion
. Zobacz partycjonowanie.