Peter,

Okay I just tested this and you're very right. It appears that RUSHMORE optimization of the WHERE is simply turned off on outer joins. And even on inner joins it appears to be a LOT slower, although it reports full optimization.

Haven't fully tested this, but this is a show stopper, as far as I'm concerned. If these results hold out in more testing, there is no way I could upgrade existing apps to 8.0 without serious performance problems.

I was thinking that maybe they changed how WHERE filters outer joins, since a filter on the outer cursor effectivly turns it into an inner join, but they didn't change this behaviour.

Has no one else brought this up yet? This is a biggie.



>Ok, I have a small internal application that I recompiled in VFP8. Mostly, no problems. BUT, I have a SELECT which is *really* slow in VFP8, and fast in VFP7.
>
>
>*Simple example:
>
>*(techs table: 25 records)
>*(call table: 150,000 records)
>
>SELECT ALL;
>"" AS NAME;
>FROM call LEFT OUTER JOIN techs ON init = UPPER(ALLTRIM(suppersn)); && this is slow.
>WHERE .F.;
>INTO CURSOR temp_stats
>
>This should be really fast, as the WHERE should be evaluated before the JOIN. But it isn't (or doesn't seem to be).
>
>Now, in VFP7, this takes at least 0.00 seconds. (The real query takes .27 seconds)
>
>VFP8, at least .57 seconds. (the real query takes > 4 seconds)
>
>Any thoughts?