Разница в производительности: условие помещено в предложение INNER JOIN и WHERE.

Скажем, у меня есть таблица order, поскольку

id | clientid | type | amount | itemid | date
---|----------|------|--------|--------|-----------
23 | 258      | B    | 150    | 14     | 2012-04-03
24 | 258      | S    | 69     | 14     | 2012-04-03
25 | 301      | S    | 10     | 20     | 2012-04-03
26 | 327      | B    | 54     | 156    | 2012-04-04

• clientidявляется внешним ключом обратно к clienttable
• itemidявляется внешним ключом обратно к элементу таблице
• типу является только B или S
• количество является целым числом

и таблица , обработанная как

id | orderid | processed | date
---|---------|-----------|---------
41 | 23      | true      | 2012-04-03
42 | 24      | true      | 2012-04-03
43 | 25      | false     | <NULL>
44 | 26      | true      | 2012-04-05     

, мне нужно получить все строки из порядка , которые для того же идентификатора клиента на ту же дату имеют противоположные значения типа . Имейте в виду, что typeможет иметь только одно из двух значений — Bили S. В приведенном выше примере это будут строки 23и 24.

Другое ограничение заключается в том, что соответствующая строка в processingдолжна быть trueдля orderid.

Мой запрос на данный момент

SELECT c1.clientid,
       c1.date,
       c1.type,
       c1.itemid,
       c1.amount,
       c2.date,
       c2.type,
       c2.itemid,
       c2.amount

FROM   order c1
INNER JOIN order c2 ON c1.itemid    =  c2.itemid AND
                       c1.date      =  c2.date   AND
                       c1.clientid  =  c2.clientid AND
                       c1.type     <>  c2.type AND
                       c1.id        <  c2.id

INNER JOIN processed p1 ON p1.orderid   =  c1.id AND
                         p1.processed =  true
INNER JOIN processed p2 ON p2.orderid   =  c2.id AND
                         p2.processed =  true

ВОПРОС: Сохранение обрабатываемого = истинногокак части предложения соединения замедляет выполнение запроса. Если я перенесу его в предложение WHERE, производительность будет намного лучше. Это пробудило во мне интерес, ия хотел бы знать, почему.

Первичные ключи и соответствующие столбцы внешнего ключа индексируются, а столбцы значений (value, processingи т. д.) — нет.

Отказ от ответственности: я унаследовал эту структуру БД, и разница в производительности составляет примерно 6 секунд.