>As for the case when SELECT is slower than COPY ... WHILE. This is >understandable if the extracted set is very small compared with the >complete table. You can have better results even if you have an index and >an Rushmore expression. Yes, that was exactly the case: it pulls an item's history from overall traffic, so it comes to couple of dozen records from 20-100K records. The idea, in the first place, was that we don't have to read the complete index (as Rushmore probably tries to), but seek the first record, and scan for the rest - in both cases it has to find exactly these records, so that part of the table will be read anyway; the gain came from reading only a little part of the index. >As I said other time, this is why is good to do tests! You have better >apps, isn't it? :) > >Vlad Of course. Every time something sounds fishy, or not as quick as expected - well, let's see... I've tried the Index on Deleted() in FPD. I've replicated one of the tables to a size of 20M, and tried an SQL select on it with and without the extra tag. No good - the results came to be about the same. Then I've deleted every twelveth record. It was quicker without the extra tag (!), thoug tnot much. Conclusion: indexing on deleted() may help you pull data, but I've had lots of calculated fields, grouped on two fields, so I guess the selecting took less time, but crunching the records took at least equally much. Then I tried with two calculated fields less - and the time decreased slightly, about 1-2%. Then my daughters wanted to play Need4Speed, so I had to make some room on my disk, and zapped the table :)