>>Daniel,
>>
>>>I assume that each of the fields being joined and/or filtered on are indexed (including deleted). If not, that may also help.
>>
>>Indexing on DELETED() is seldom a good idea. Actually this might be Nadyas problem. Indexes on deleted() on large tables create a massive overhead which might be very well the cause of her problems. It's generally proven that DELETED() tags almost never helpfull in gaining performance, but could make you app terrible slow.
>>
>>Walter,
>
>Damm, looks like I've got some changes to make. Still, my first idea, back at the begining of this tread, to split the query up, seems to have been the solution...

Hi Daniel,

Yes, splitting query by two made a significant perfomance gain. I also got rid of deleted tags for test purposes. But right now we decided to check another idea. We have TranMstr table, which holds all transcations for each property. We also have PropMstr table and SiteMstr table (first holds the current property situation (last owner, last sale price, etc.) and SiteMstr holds address info about property). We have ccode+town in PropMstr and SiteMstr, but we don't have them in TranMstr. We decided to make an experiment and de-normalize TranMstr by adding ccode and town fields in there (6chars*5mln. rec.). It should speed up all statistical queries, because we would not need to join to SiteMstr in this case). So, right now I'm running table update (too bad, I started it on my local machine, instead of the server)...