Публикувах плана ви за заявка на objasni.depesz.com, вижте.
Прогнозите на инструмента за планиране на заявки са ужасно грешни на някои места. Изпълнили ли сте ANALYZE наскоро?
Прочетете главите в ръководството за статистически данни, използвани от планировщика и константи на разходите за плановик. Обърнете специално внимание на главите за random_page_cost и default_statistics_target .
Можете да опитате:
ALTER TABLE diplomas ALTER COLUMN number SET STATISTICS 1000;
ANALYZE diplomas;
Или отидете дори по-високо за таблица с 10 милиона реда. Зависи от разпределението на данните идействителните заявки . Експериментирайте. По подразбиране е 100, максимумът е 10000.
За база данни с такъв размер само 1 или 5 MB work_mem като цяло не са достатъчни. Прочетете страницата на Postgres Wiki в Tuning Postgres, към която има връзка @aleroot.
Тъй като вашата заявка се нуждае от 430104 kB памет на диск според EXPLAIN изход, трябва да зададете work_mem до нещо като 500MB или повече, за да позволите сортиране в паметта. Представянето на данни в паметта изисква малко повече пространство, отколкото представянето на диска. Може да се интересувате от това, което Том Лейн публикува наскоро по този въпрос.
Увеличаване на work_mem само с малко, както опитахте, няма да помогне много или дори може да се забави. Задаването му на високо глобално може дори да навреди, особено при едновременен достъп. Множество сесии могат да се нуждаят една друга от глад за ресурси. Разпределянето на повече за една цел отнема памет от друга, ако ресурсът е ограничен. Най-добрата настройка зависи от цялата ситуация.
За да избегнете странични ефекти, задайте го само достатъчно високо локално във вашата сесия и временно за заявката:
SET work_mem = '500MB';
След това го нулирайте до стандартните си стойности:
RESET work_mem;
Или използвайте SET LOCAL за да го зададете само за текущата транзакция за начало.
