David,

>>It was a myth because in 99% of all cases it did nothing to enhance performance or was slowing queries down. I've identified three cases in where it might be beneficial which are on itself exceptions. The only one that does make sense is the COUNT statement.

>You make this statement based upon the way that your app works. Your app is not everyone's app and therefore each developer needs to evaluate the cost/benefit on their own. Not every query need be a NOFILTER result set. So I'd say your 99% estimate is just a tad high. *s*

I'm not talking about anyones app. Only if you produce filtered SQL SELECT results you benefit the DELETED() tag. But then the question is, why do you use a SQL SELECT at all. Just set a filter (SET FILTER) and you're done also.

>>A developer should understand when to use indexes and how they are used. This is the main problem here. I wrote the messages back then because I knew how the indexes were used and that the general accepted knowledge was humbug because the logic was false.

>Sorry, I don't think that was the case at all. A lot of people understood how the rushmore bitmap works. The deciding performance factor becomes when does the bitwise selectivity do better than the cost to suck the index across the wire vs the time it takes to bring the data row across the wire vs the size of the wire vs the size of the data vs the network loads vs contention for the data. There are just a whole lot of variables involved here Walter.

Again, you don't show to understand the issue here. If there are no or very little deleted records in the table, the DELETED() tag means overhead. Rushmore is going to process the index information while as a netto result it does nothing. You've wasted CPU/NETWORK/DISK IO. Even with the filtered SQL SELECT, If you're going to SCAN it, it will result in more network trafic and CPU resources used as with every skip it needs to process the index information again.

>>Many people tested on their local machine in stead of a network where the network is the bottleneck, not giving reliable indications of its performance in production time. Also many people are not aware of network optimizations like exclusive oplocking so that even when testing over a network they get false measures.

>There are cases, and a lot more of them in the past, where the data did actually live on the user machine not a file server. So another big factor is where the data resides.

Again, the best case indeed is on a workstation. You can get the impression the query executed lightning fast as oposed to a non-filtered query, but most likely will lose the won time when processing it since then VFP has to process index information for every record. Again when there are no deleted records, you win nothing.

>>I was stunned back in 1999 that so little people (in fact I encountered none at the time), who really understood how rushmore optimized queries. Even from the side of MS there is no usable explanation telling you this.

>You expect Microsoft to release great detail on one of the things that has always made FoxPro faster than the competition? Don't ever expect any company to release such intellectual property.

BOGUS. I'm not talking about how the product is working internally (hell I don't know either), but giving more information how it works logically would be nice. BTW, this information *IS* available for SQL server, so here goes your argument.

>>Unfortunately, the binary index is a miss. Though much smaller it really does not adress the problem: Low selectivity and therefore it does not change much to the story. If the deleted() tag is not going to weed out (many) deleted() records it use is useless.
>
>Is this based on actual tests or just a supposition?

Again, you don't see it. It is the concept that does not make much sense. You can do your tests and find it does do its job in your cases, but do not realize it crashes in others. If you understand the concept you'll see inmediately.

>>People are given a false indication that full optimization is better than partial optimization.

>Again developers need to see which is actually faster in their environment.

No, developers should understand why something is better than the other. Emperical tests are not giving you reliable information of an production environment. Knowledge and understanding is.

Walter,