[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Question about the performance of ABL queries resolved by multiple indexes

Status
Not open for further replies.
D

dbeavon

Guest
>> If I remember correctly, the index read numbers you see are not counting number of index entries accessed in the index pages. This would make sense, or else the numbers should be around a million for the number of matching ROWID's *within* the index pages of each of those three indexes. So it must be that the index stats are omitting the "short-circuited" reads on the *pages* of an index. Or it may be the case that it is the *pages* that are always being counted, rather than the number of ROWID's within the index pages. The "Reads" column header for the OEE indexes is ambiguous and I suppose it doesn't necessarily correspond to individual ROWID's. (Unlike the creates/deletes/updates at the table level which are almost always understood to refer to individual rows). I really appreciate the tips. The performance makes more sense if the query is not accessing the table, but only the index pages. It is unfortunate that the SQL count(*) operation is not doing a similar thing. Otherwise that should be blazing fast too. What still doesn't make sense is why the compiler would prefer the three single-column indexes over a single multi-column index. There are actually a couple of them that start with the three fields in question. Here is one example: fin_gl3 -fy -period -div -acct This would resolve the query faster, if the compiler used it. And it would have a less sophisticated query plan.

Continue reading...
 
Status
Not open for further replies.
Top