Разходни параметри за планиране
Това ми казва, че вашата random_page_cost и seq_page_cost вероятно са грешни. Вероятно използвате хранилище с бърз произволен I/O - или защото по-голямата част от базата данни е кеширана в RAM, или защото използвате SSD, SAN с кеш или друго хранилище, където произволният I/O е присъщо бърз.
Опитайте:
SET random_page_cost = 1;
SET seq_page_cost = 1.1;
за значително намаляване на разликите в параметрите на разходите и след това стартирайте отново. Ако това върши работа, помислете за промяна на тези параметри в postgresql.conf. .
Вашите прогнози за броя на редовете са разумни, така че не изглежда като проблем с грешна оценка на плановика или проблем с лоша статистика на таблицата.
Неправилна заявка
Вашето запитване също е неправилно. OFFSET 0 LIMIT 1 без ORDER BY ще доведе до непредвидими резултати, освен ако не е гарантирано, че имате точно едно съвпадение, в който случай OFFSET ... LIMIT ... клаузите са ненужни и могат да бъдат премахнати изцяло.
Обикновено е много по-добре да формулирате такива заявки като SELECT max(...) или SELECT min(...) където е възможно; PostgreSQL ще има тенденция да може да използва индекс, за да извлече желаната стойност, без да прави скъпоструващо сканиране на таблица или сканиране на индекс и сортиране.
Съвети
Между другото, за бъдещи въпроси PostgreSQL wiki има добра информация в категория за производителност и ръководство за задаване на въпроси за бавни заявки .
