It is obviously not very quick but a simple utility routine could
be called which could create a new table, insert enough data that
would then flush every existing page from the cache and it's size which
I don't know if it is program gettable but could at least be hard
coded to default. This routine
of course would depend on the behaviour of the cache in question. So
if it got smarter to avoid a table scan or a table load from flooding
the cache and bumping everything then it would not work.
I personally would find such an internal testing interface useful, but
do wish there was easy way to make it available to our tests but not
to general user usage.
/mikem
Knut Anders Hatlen wrote:
Bryan Pendleton <[EMAIL PROTECTED]> writes:
Mike Matrigali (JIRA) wrote:
affects page 0, which happens to be accessed a lot and thus is in
cache a lot.
Perhaps it would be helpful to add a special internal testing API
which enables test programs to discard the cache at interesting moments?
I know special testing hooks are gross, but sometimes they can also be
really helpful for enabling better testing.
It shouldn't be too difficult to implement, I think. The CacheManager
interface already has the needed functionality through these methods:
- ageOut() - removes all clean objects that are not held
- discard() - same as ageOut(), but also removes dirty objects
(without cleaning them)
For the statement cache, ageOut() is exposed to the users via the stored
procedure SYSCS_UTIL.SYSCS_EMPTY_STATEMENT_CACHE(). We could probably do
something similar for the page cache and the container cache.
