Някои проблеми се открояват:
Първо, помислете за надграждане до текуща версия на Postgres . Към момента на писане това е pg 9.6 или pg 10 (в момента бета). От Pg 9.4 има множество подобрения за GIN индексите, допълнителния модул pg_trgm и големите данни като цяло.
След това имате нужда от много повече RAM , по-специално по-висок work_mem настройка. Мога да разбера от този ред в EXPLAIN изход:
Heap Blocks: exact=7625 lossy=223807
"загубено" в подробностите за сканиране на купчина растерни изображения (с вашите конкретни числа) показва драматичен недостиг на work_mem . Postgres събира само адреси на блокове в сканирането на растерния индекс вместо указатели на редове, защото се очаква това да бъде по-бързо с вашия нисък work_mem настройка (не може да съдържа точни адреси в RAM). Много повече редове, които не отговарят на условията, трябва да бъдат филтрирани в следното Сканиране на купчина растерни изображения насам. Този свързан отговор съдържа подробности:
Но не задавайте work_mem също високо, без да се отчита цялата ситуация:
Възможно е да има други проблеми, като раздуване на индекс или таблица или повече затруднения в конфигурацията. Но ако коригирате само тези два елемента, заявката трябва да бъде много вече по-бързо.
Също така, наистина ли трябва да извлечете всички 40k реда в примера? Вероятно искате да добавите малък LIMIT към заявката и я направете търсене на „най-близкия съсед“ – в който случай GiST индексът е по-добрият избор в крайна сметка, защото това се предполага, че е по-бърз с GiST индекс. Пример:
