Hi Walter,

I started a lengthy reply, but unfortunately IE decided to quit without letting me send the mail, so here a shorter one:

>Besides that, The example you showed is not quite common. In the majoraty of cases you would include one or more fields from table B.

Nope, my query applies for example to the following situation: I need a list of all articles I've on stock. That returns only article records, but requires a join on the stock table.

And Walter, there's a simple reason why no-one yet had proven the opposite of what you claim:

1. You insist on queries that return non-filtered records, although in these tests you don't measure the time it takes to run the query, but the time it takes to transfer the records to the local computer.

2. You haven't yet proven that your conclusions are true for x-table joins.

3. You concentrate on simple SELECT commands that return records that match a certain condition.

4. Your samples don't take into account that most of the records are in the local cache.

Let me give a sample that is quite common and clearly demonstrates that you are wrong:

Clear All
Close ALl
Release ALl
Set Deleted on
Create Table Sample (cField C(254))
For t=1 to 10000
Append Blank
Endfor

nStart = Seconds()
Count to a
? Seconds() - nStart

Index on Deleted() Tag _Deleted
nStart = Seconds()
Count to a
? Seconds() - nStart

This program takes 30 times more time to execute without index on DELETED(). Even when I replace COUNT with SELECT CNT(*), it takes up to 15 times more. And please don't tell me that this is not a common query. Many application count the number of records that match a condition before actually running the query, especially when the network connection is slow and they want to give the user the opportunity to cancel the search.

If you look, you can definitely find a lot more samples where data grouping, summing values, etc. is involved.


Christof