Тази заявка не доведе до I/O на диска – всички блокове се четат от споделени буфери. Но тъй като заявката чете 73424 блока (около 574 MB), тя ще доведе до значително I/O натоварване, когато таблицата не е кеширана.
Но има две неща, които могат да бъдат подобрени.
-
Имате загубени блокови съвпадения в сканирането на купчина. Това означава, че
work_memне е достатъчно голям, за да съдържа растерно изображение с бит на ред от таблица, а вместо това 26592 бита картографират блок от таблица. Всички редове трябва да бъдат проверени отново и 86733 реда се отхвърлят, повечето от които са фалшиви положителни резултати от съвпаденията на блокове със загуба.Ако увеличите
work_mem, растерно изображение с бит на ред на таблица ще се побере в паметта и това число ще се свие, намалявайки работата по време на сканирането на купчина. -
190108 реда се отхвърлят, защото не отговарят на условието за допълнително филтриране при сканирането на купчина растерни изображения. Тук може би се прекарва най-много време. Ако можете да намалите тази сума, ще спечелите.
Идеалните индекси за тази заявка биха били:
CREATE INDEX ON map_listing(transaction_type, la); CREATE INDEX ON map_listing(transaction_type, lo);Ако
transaction_typeне е много селективен (т.е. повечето редове имат стойностSale), можете да пропуснете тази колона.
РЕДАКТИРАНЕ:
Проверка на vmstat и iostat показва, че както CPU, така и I/O подсистемата страдат от масивно претоварване:всички ресурси на CPU се изразходват за I/O чакане и време за кражба на VM. Нуждаете се от по-добра I/O система и хост система с повече свободни процесорни ресурси. Увеличаването на RAM може да облекчи I/O проблема, но само за четене на диска.
