Daniel John Debrunner wrote:
Suresh Thalamati (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-239?page=comments#action_12316434 ]
Suresh Thalamati commented on DERBY-239:
----------------------------------------
[comments just on this issue]
b) read each pages in to the page cache first and then latch the
page in the cache until a temporary copy of it is made. This approach
does not have extra overhead of extra latches on the page keys during writes , but
will pollute the page cache with the pages that are only required by the
backup; this might have impact on user operations because active user pages may
have been replaced by the backup pages in the page cache.
or
c) read pages into buffer pool and latch them while making a copy similar to
the above approach, but some how make sure that user pages are not kicked out
of the buffer pool.
I think b) is the correct approach, but what is 'buffer pool' in c)?
I think modifications to the cache would be useful for b), so that
entries in the cache (through generic apis, not specific to store) could
mark how "useful/valuable" they are. Just a simple scheme, lower numbers
less valuable, higher numbers more valuable, and if it makes it easier
to fix a range, e.g. 0-100, then that would be ok. Then the store could
added pages to the cache with this weighting, e.g. (to get the general idea)
pages for backup - weight 0
overflow column pages - weight 10
regular pages - weight 20
leaf index pages - weight 30
root index pages 80
This weight would then be factored into the decision to throw pages out
or not.
This project could be independent of the online backup and could have
benfits elsewhere.
Dan.
"buffer pool" is hangover from my old job, I meant "page cache" in
option c). I also think b) is the correct approach,
if the cache can be enhanced as you described.
Thanks
-suresht
