Когато имате и LIMIT, и ORDER BY, оптимизаторът е решил, че е по-бързо да накуцва през нефилтрираните записи на foo чрез низходящ ключ, докато получи пет съвпадения за останалите критерии. В останалите случаи той просто изпълнява заявката като вложен цикъл и връща всички записи.
Накратко, бих казал, че проблемът е, че PG не удря ставата разпределение на различните идентификатори и затова планът е толкова неоптимален.
За възможни решения:ще приема, че сте стартирали ANALYZE наскоро. Ако не, направете го. Това може да обясни защо прогнозните ви времена са високи дори на версията, която се връща бързо. Ако проблемът продължава, може да изпълните ORDER BY като подизбор и да поставите LIMIT във външна заявка.
