Nadya,

>If we want to take your route, we have to have two indexes. One with filter and another without for Rushmore. For 5mln. records table I don't think, it's good to add this index.

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 bytes (like an integer) I doubt you would ever see the performance difference. The best test, of course, is to test both situations.

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 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,