Re: Very Severe Performance Problems on my 7.22 UC2

David Williams wrote : >>> OPTCOMPIND 2> OPTCOMPIND=2 thus favouring sequential scans, Well, not really, at least that's not the way its *supposed* to work. With a value of 2 for OPTCOMPIND, the optimizer is supposed to consider both indexed access and dynamic hash joins and CHOOSE THE LESS COSTLY METHOD. It *should* not choose a hash join if the cost of the index access is lower. Setting OPTCOMPIND to 0 eliminates dynamic hash joins from consideration. Typically, that will force the optimizer to choose an index access, but it is by no means guaranteed (a common situation is to see sequential scans as a result of having not updated statistics for the tables in question). That all said, empirical evidence may point to seq scans with OPTCOMPIND set to 2, but that is NOT the intended behavior. -- Dave "That's just my opinion - I could be wrong." - Dennis Miller