Subject | IB6 sequential scan improvement |
---|---|
Author | Corey Wangler |
Post date | 2000-11-08T04:54:03Z |
Ann,
I'm not sure if the document is still available, but
ibp_60_seq_scan_fs.html
described the new feature of IB 6.0 where the cache
management is improved such that large sequential scans
do not clear out the cache.
The document said:
A "large" sequential scan is defined as a scan
where the count of pages to be retrieved is greater
than the number of page buffers in the cache.
(see end of message for more of that document).
What I'm wondering here is if this feature could
be altered to allow a setting for the number of
page buffers that defines a "large" sequential
scan? Maybe as a percentage of the available
buffers (e.g. 25%)?
Such a setting could be used to make it such that
a given user cannot take over the entire cache
when doing such operations. By the sounds of the
current definition, a scan that grabs just less
than the total number of pages could still cause
problems....
Comments?
Cheers,
Corey.
Corey Wangler
Designed Software Solutions
Adelaide, Australia.
========================================================
Excerpt from ibp_60_seq_scan_fs.html
========================================================
A "large" sequential scan is defined as a scan
where the count of pages to be retrieved is greater
than the number of page buffers in the cache. This
is an arbitrary definition but one which has certain
properties and conservative underpinnings which will
minimize this feature's effect on existing applications.
The current behavior of a large sequential scan reads
each page as the most recently used (MRU) page. This has
the effect of replacing every resident page with pages
from the sequential scan even though once the last item
from each sequential page is accessed it will never be
accessed again by this operation.
It is proposed that this behavior of sequential scans be
amended such that each page of a large sequential scan be
queued as the Least-Recently-Used (LRU) page so that the
page buffer it occupies can be reused by the scan or any
other user for that matter.
========================================================
I'm not sure if the document is still available, but
ibp_60_seq_scan_fs.html
described the new feature of IB 6.0 where the cache
management is improved such that large sequential scans
do not clear out the cache.
The document said:
A "large" sequential scan is defined as a scan
where the count of pages to be retrieved is greater
than the number of page buffers in the cache.
(see end of message for more of that document).
What I'm wondering here is if this feature could
be altered to allow a setting for the number of
page buffers that defines a "large" sequential
scan? Maybe as a percentage of the available
buffers (e.g. 25%)?
Such a setting could be used to make it such that
a given user cannot take over the entire cache
when doing such operations. By the sounds of the
current definition, a scan that grabs just less
than the total number of pages could still cause
problems....
Comments?
Cheers,
Corey.
Corey Wangler
Designed Software Solutions
Adelaide, Australia.
========================================================
Excerpt from ibp_60_seq_scan_fs.html
========================================================
A "large" sequential scan is defined as a scan
where the count of pages to be retrieved is greater
than the number of page buffers in the cache. This
is an arbitrary definition but one which has certain
properties and conservative underpinnings which will
minimize this feature's effect on existing applications.
The current behavior of a large sequential scan reads
each page as the most recently used (MRU) page. This has
the effect of replacing every resident page with pages
from the sequential scan even though once the last item
from each sequential page is accessed it will never be
accessed again by this operation.
It is proposed that this behavior of sequential scans be
amended such that each page of a large sequential scan be
queued as the Least-Recently-Used (LRU) page so that the
page buffer it occupies can be reused by the scan or any
other user for that matter.
========================================================