Walter,

Actually, these are our core tables, so I can not modify them without discussing with all team members first. OTOH, I have a replication on my local drive of our whole system, so I may try there, but I just haven't time yet to test.

>
>I don't think much would change. I guess that your 5mln table is some kind of statistical table that does not change much. If you PK field is only a few

No, it changes every week.

bytes (like an integer) I doubt you would ever see the performance difference. The best test, of course, is to test both situations.

PK is Integer.

>B.T.W. did you test dropping the DELETED() indexes ? did you use an DELETED() index on this 5 mln table ? I strongly suggest you do drop this one. You could

Yes, we have DELETED() index in all our tables. It was a decision made while ago. I tried to raise in issue in one of my e-mails, but we hadn't have a real discussion here. I may raise it again, when we would address optimization issues. Currently our main purpose is to prepare the first Release by January. Then would be time for all enhancements/modifications, etc. Currently several of my ideas are put on hold. For example, while ago I modified our base classes to improve the speed of loading (I used Trey Walpole idea of invoking a common peace of code by SetAll logical property). Originally they use recursive walk through all controls. I made bunch other changes as well. Still we don't use the improved version of classes... It's just an explanation, what sometimes in our environment even great ideas should wait...


significanly speed up your app by dropping this three headed dragon.
>
>>My idea looks interesting to me (though it would require some code changes, I believe), but I haven't proposed it yet between our team members. Curious, what other UTrs think about it.
>
>It sure would work, but personally think that my solution is more clean. It is only a pitty that rushmore cannot use a filtered index. If this would be possible it could mean we would have a whole new mechanism to speed up queries. By my knowledge there is no other (R)DBMS which has such a optimizing mechanism.
>
>Walter,