D
dbeavon
Guest
I didn't try those prefetch parameters yet. But I did see some references to them and I have it on my list to investigate. Given that I am new to client-server I didn't want to jump in so deeply yet. I believed the defaults would suffice. But my concern is (still) that there is something is going on internally that treats "FOR EACH NO-LOCK" differently based on whether it is using the "perfect" index or not. I noticed the default prefetchNumRecs is 16. My theory is that this number is treated as the number of candidate records that are evaluated via the selected index. In the case of a "perfect" index, this may return 16 consecutive matches that all get shoved over the network in a single round-trip. But if a bad index is used then perhaps 16 records are scanned in the base table, and only some small portion of them get shoved over the network in the client-server round-trip. This is all conjecture based on the differences I see in the network traffic between the two cases (whether or not there is a "perfect" index). Here are the parameters I plan to test with : -prefetchFactor 100 -prefetchNumRecs 100 -prefetchDelay (allows the first round-trip to contain more than a single record) FYI, I found another discussion about prefetch* parameters here: community.progress.com/.../20822 I will test these parameter asap and let you know if they eliminate the differences I see in the FOR EACH NO-LOCK. (Differences between the case where it uses a "perfect" index and the case it does not).
Continue reading...
Continue reading...