Причината, поради която виждате разлика, се дължи на плана за изпълнение, който планиращият съставя, това очевидно е различно в зависимост от заявката (вероятно трябва да оптимизира 2-те заявки, за да бъдат еднакви и това може да е грешка ). Това означава, че планиращият смята, че трябва да работи по определен начин, за да стигне до резултата във всяко твърдение.
Когато го направите в рамките на JOIN, плановникът вероятно ще трябва да избере от таблицата, да филтрира по частта "True", след което да присъедини наборите от резултати. Предполагам, че това е голяма таблица и следователно много данни за разглеждане и не може да използва индексите толкова ефективно.
Подозирам, че ако го направите в клауза WHERE, плановникът избира маршрут, който е по-ефективен (т.е. базиран на индекс, или предварително филтриран набор от данни).
Вероятно бихте могли да накарате присъединяването да работи толкова бързо (ако не и по-бързо), като добавите индекс към двете колони (все още не съм сигурен дали включени колони и множество индекси на колони се поддържат в Postgres).
Накратко, проблемът в планировщика е, че избира 2 различни маршрута, за да стигне до наборите от резултати, и единият от тях не е толкова ефективен, колкото другият. За нас е невъзможно да разберем какви са причините без пълната информация за таблицата и информацията EXPLAIN ANALYZE.
Ако искате да уточните защо вашата конкретна заявка прави това, ще трябва да предоставите повече информация. Причината обаче е, че планиращият избира различни маршрути.
Допълнителен материал за четене:
http://www.postgresql.org/docs/current/static/explicit-joins.html
Току-що бегло, изглежда, че планерът на postgres не пренарежда присъединяванията, за да го оптимизира. опитайте да промените реда на съединенията във вашето изявление, за да видите дали след това ще получите същото представяне... само една мисъл.
