Subject | Re: [Firebird-Architect] Bi-directional indexes |
---|---|
Author | Dmitry Yemanov |
Post date | 2005-06-25T10:20:41Z |
"Ann W. Harrison" <aharrison@...> wrote:
1) tries a no wait handoff to the left sibling page
2) if successful, we're done
3) otherwise, refetch the current page (125) for write
4) mark it with btr_dont_gc and release
5) fetch the left sibling page
6) handoff right sibling pointers until the remembered page (125) is found
7) fetch the remembered page (125) for write, clear btr_dont_gc and release
Could this work? Yeah, it requires two page writes per every backward scan
conflicting with a page modification, but perhaps it's acceptable?
Dmitry
>The backward reader keeps a read lock on page 125, then:
> So why does compression alter all this? If while page 124 was
> splitting, page 125 was compressed and released from the index, the
> backward walker can walk forward all day and will never find its
> starting point. Or, page 125 could have been released from one part of
> the index, then reused somewhere else in the same index.
1) tries a no wait handoff to the left sibling page
2) if successful, we're done
3) otherwise, refetch the current page (125) for write
4) mark it with btr_dont_gc and release
5) fetch the left sibling page
6) handoff right sibling pointers until the remembered page (125) is found
7) fetch the remembered page (125) for write, clear btr_dont_gc and release
Could this work? Yeah, it requires two page writes per every backward scan
conflicting with a page modification, but perhaps it's acceptable?
Dmitry