Parametry kosztów Planera
To mówi mi, że Twój random_page_cost i seq_page_cost prawdopodobnie się mylą. Prawdopodobnie korzystasz z pamięci masowej z szybkimi losowymi operacjami we/wy — albo dlatego, że większość bazy danych jest buforowana w pamięci RAM, albo dlatego, że używasz dysku SSD, SAN z pamięcią podręczną lub innej pamięci masowej, w której losowe operacje we/wy są z natury szybkie.
Wypróbuj:
SET random_page_cost = 1;
SET seq_page_cost = 1.1;
aby znacznie zmniejszyć różnice parametrów kosztów, a następnie ponownie uruchomić. Jeśli to wystarczy, rozważ zmianę tych parametrów w postgresql.conf. .
Twoje szacunki dotyczące liczby wierszy są rozsądne, więc nie wygląda to na problem z błędną oceną planisty lub problem ze złymi statystykami tabeli.
Nieprawidłowe zapytanie
Twoje zapytanie jest również nieprawidłowe. OFFSET 0 LIMIT 1 bez ORDER BY da nieprzewidywalne wyniki, chyba że masz gwarancję dokładnie jednego dopasowania, w którym to przypadku OFFSET ... LIMIT ... klauzule są niepotrzebne i można je całkowicie usunąć.
Zwykle dużo lepiej jest formułować takie zapytania jak SELECT max(...) lub SELECT min(...) tam, gdzie to możliwe; PostgreSQL będzie miał tendencję do używania indeksu, aby po prostu wybrać żądaną wartość bez wykonywania kosztownego skanowania tabeli lub skanowania indeksu i sortowania.
Wskazówki
BTW, w przypadku przyszłych pytań wiki PostgreSQL zawiera dobre informacje w kategorii wydajności oraz przewodnik dotyczący zadawania Pytań dotyczących powolnych zapytań .
