[mensagem longa]

Verifiquei o que me enviou e tenho algumas consideração (que podem não ser verdadeiras :D)

Select Sum(Faturamento_03b.QtdOri - Faturamento_03b.QtdEfe) As Qtdade;
   From Faturamento_03b Left Outer Join Faturamento_03a;
   On Faturamento_03b.Processo = Faturamento_03a.Processo;
   Where Faturamento_03b.Item = "MO             " .and.;
         Faturamento_03b.QtdOri > Faturamento_03b.QtdEfe .and.;
         Faturamento_03a.OP_Reserva = "S";
   Into Cursor Teste

Observe que a única coisa que realmente esta sendo usada o rushmore é o "processo", porém, ele não esta na WHERE, assim o sistema tem que percorrer toda a tabela, validar a where (que tem 2 tabelas) para dai sim fazer com que o inner join realmente funcione.

Note que neste caso a parte que cabe ao rushmore é insignificante, e até atrapalha, visto que ele tem que ficar verificando a 03a.OP_Reserva, depois disparar o rushmore, fazer a consulta, voltar a 03a para o ponteiro que esta no where (isso na minha singela ignorancia)...

Se você quiser que o rushmore realmente trabalhe nesta select, crie indices para os campos da clausula Where, mas eu não coloquei para o OP_Reserva, visto que como é apenas 1 caracter não sei o que tem nele e como ficaria balanceado.

Resultados:

Com indices do Join: 13 Segundos
Sem indices do Join: 14 Segundos

Colocando indices nas WHERE (03b.Item e 03b.QtdOri)

Sem rushmore : 17 Segundos
Com rushmore : 2 Segundos

Conclusão: A otimização mais importante é a do Where, se você tem que percorrer toda a tabela para dai executar um join otimizado, não vai adiantar muito.