<<The prefetch flag in DBUTIL actually doesn't have anything to do with
prefetch as we understand it from a file I/O perspective.  Its function
is to allow you to reduce the amount locking around certain transactions.
 In other words, if a transaction (and I don't recall which ones are
specifically indicated here) has 10 steps with the lock/unlock, the SET
dbname PREFETCH will reduct the number of steps within the lock/unlock
pair. This was all explained in detail in an old Performance Notes
document that used to come out with the quarterly SSB's.>>
 
My understanding (for what *that's* worth) is a little different:
PREFETCH allows the IMAGE engine, during a DBPUT or DBDELETE operation,
to go ahead and retrieve data from other sets that would normally be
retrieved only after the current operation is complete. IOW, these
operations frequently require updates to multiple sets, and normally
IMAGE completely finishes processing an entire PUT/DELETE operation
before starting any part of the next one, even if they have nothing to do
with each other as far as the sets being changed. PREFETCH allows IMAGE
to start the retrieval operations needed for the next PUT/DELETE even
though the current one is not completely finished. As such, it doesn't
have anything to do with locking per se, but *does* fall into the typical
file I/O "prefetching" concept.
 
Obviously, PREFETCH is only going to give you a performance advantage if
the database has a reasonably high occurrence of simultaneous PUT/DELETE
requests coming in at the same time from different users.
 
Although the manual doesn't mention it, I'd also guess that a DBUPDATE
with a search item being modified now falls into this category.
 
There are a few words on page 4-20 of the IMAGE manual, under the
"Coordinating Deletions from a Database" heading.
 
Steve Dirickson         WestWin Consulting
(360) 598-6111  [log in to unmask]