PCContraR1K0Да, про JOIN я читал, но как-то олдскул уже в крови (да и, скорее всего, это не более чем syntax sugar, или я не прав?), а пример с WITH уж больно громоздкий имхо, Хотя, конечно, блочность упрощает отладку в особо крутых запросах.
Мои вопрос скорее в том, что же в общем случае лучше - подзапросы или связь таблиц?
R1K0 , синтаксическим подсластителем JOIN не являются. Запросы с ними выполняются намного быстрее. В вашем случае
1.
2.
3.
4.
5.
SELECT td.name, td.layer, td.linktype_id
FROM taskdesc AS td, questdesc AS qd, questtasklink AS qtl
WHERE qtl.quest_id = qd.quest_id
AND qtl.task_id = td.task_id
AND qd.name = 'Begin Training'
происходит сравнение каждой строки таблицы с каждой строкой другой таблицы. Зависимость для двух таблиц будет квадратичная, для трех - в кубе (при равном числе записей, ну а для разного количества - равно их произведению). Механизм Join'ов отличается, по факту он работает куда быстрее. Сужу по своему опыту
cross join (т.е. декарт) с фильтром where как правило распознаётся и планируется оптимизатором постгреса
в точности так же , как INNER JOIN с соответствующим (фильтру кросса) условием связи в ON (using). само предложение (CROSS|INNER|OUTER) за скорость связывания не отвечает, никакой магии в слове INNER (или JOIN) нет
за некое ускорение в разных случаях могут отвечать правильно созданные индексы + правильно (в соответствии с построенными индексами) наложенные условия. (можно написать условие [и в ON и в WHERE] так, что оптимизатор не сможет воспользоваться годным под него индексом)
кроме всего прочего, join отличается от изначальной задачи (exists|in) в случае проверок по не ключевым полям. (по ключевым -- и планы [exists | inner], как правило, совпадают, иногда на удивление). И тогда потребует дополнения DISTINCT-ом, что всегда плохо.
