At 11:48 AM 9/16/96 P, Steve Dirickson b894 WestWin wrote:
/snip
 
>Before we decide, we probably need to hear the rest of the story; i.e.,
>we've heard the "benefit" side-what is the "cost"? I would assume that
>prefetch costs more in terms of CPU time, memory, disk space, or
>something of value (unless TANSTAAFL has been repealed). Maybe Adager
>could analyze these other aspects, and only make the recommendation if
>the cost in terms of these other quantities is offset by the benefit in
>TurboIMAGE performance.
 
For more background, those who may not be understand how pre-fetch works, I
would recommend getting a copy of a note on pre-fetch that Ken Paul wrote
sometime towards the end of July.
 
In his note Ken outlined that under certain circumstances enabling pre-fetch
could impact overall performance due to re-reading IMAGE blocks because the
put-delete semaphore was not held during the staging of the transaction.
The circumstances whereby it is not advisable to enable pre-fetch are
certainly the exception to the rule.  HP recognized this when this feature
was introduced.  That is why they indicated that 'your mileage may vary' and
it may or may not benefit all situations.  Their basic recommendation was
for users to try it out and see if it could benefit their particular
situation, setting the flag accordingly.
 
If a site experiences performance problems with pre-fetch and elects to not
to use it then automatically re-enabling it would mean that the DBA would
have to remember to explicitly disable it after any changes are conducted to
the specific database.  If the DBA doesn't remember/know that pre-fetch
caused problems, they may attribute the problems to the changes made to the
database itself.  As such, they could spend time searching in the wrong
direction for the root cause to their change in performance.
 
We have taken the approach with DBGENERAL of not automatically enabling this
for users because we do not know enough about the user's on-going
operational environment to make these types of decisions.
 
-- Jerry