Re: ANY IDEA ON USING INDEX FOR ORDER BY

Hi Felix Thanks for the tip. in our case the OPTCOMPIND was already set to 0, but the problem still = occurred. The funny thing was that if I dropped and recreated the 'bad' index. It = moved from being the 'first' index reported by dbschema, to being the = 'last' index reported by dbschema. Then the RDBMS would not use it, but = would use the other ('good') one. After coming back to work on Monday the index order, as reported by = dbschema, had the 'bad' index first again. (Over the weekend 'update statistics' had run. I cannot think of anything = else that would affect it). Now that the 'bad' index was first in the list again, everything slowed = down again. Tech support tell me it should make no difference - go = figger. In the end I just dropped the 'bad' index altogether, and things are = speedy again. I have a job on me to get to the bottom of this. I will post any = revelations that [may] occur. Cheers Peter >>> Felix Koshy Mathews <fmathews@systems.DHL.COM> 16/01/98 08:38:57 >>> Do you think the optimizer is the one taking you for this wild ride, then = set your config-file with OPTCOMPIND 0 # =To hint the optimizer If it is set to 1 or 2 the optimer will try its best give you better = performance, but for us it was a waist of time. So we decided to set = OPTCOMPIND to 0. If I do a query on our tables, it uses the index-key = similar to your file-id. -- Have a nice day Felix K. Mathews mailto:fmathews@systems.dhl.com=20