Hi,

>> If i understand your proposal then index-pages shouldn't be
> > collected together anymore when they get
>> under a certain threshold. Empty index pages aren't possible at
> > the moment and this will certainly lead to weird behaviour
> > (empty keys with pagenumbers in non-leaf pages somewhere in
> > the middle?).

> Index compression was added in V4, so it's certainly possible for
> an index to allow empty nodes, and probably Jim remembers how it
> worked.

I was thinking wrong while i knew better, the keys in the non-leaf pages will not change and
therfore they don't become empty, but will hold the first key from the leaf-page until the page is
totally removed.

>> Another proposal:
>> - Remember left-sibling page and current-page, key, recordnumber
>> - <time expired>
>
> OK. Lets suppose that we actually remember a key and record number
> that we have verified as being valid for our current transaction.
> That way it (probably) won't be garbage collected while we're mucking
> around trying to find our place again.
>
>> - Next record asked which is before the buffered exploded page.
>> - Fetch left-sibling page and check if next-page is current-page
>> - if found ---------------------------------------------------------|
>
> Not entirely OK. Remember that the "current page" isn't locked, so it
> could have been combined, released, and re-used while we're looking at
> its decompressed contents. As could it's left neighbor. In fact, they
> could both have been moved to the end of the index, still be neighbors,
> and not have any relationship to their former contents.

Always a lookup on the page itself must be done, that's why the next is there:

>> - not found, lookup key, recordnumber from index-root-page
>
> That works in snapshot mode, and currently works in read-committed
> read-write, but it doesn't work in read-committed read-only where the
> record whose key and record number we saved could have disappeared.

Isn't something equal done for forward walking. I can't believe that a lock is hold on a page when i
open an stream which does navigation walk with an index and fetch the records 1 by 1 with an delay
of 1 sec. ?

>> - Find key, recordnumber <--------------------------------------|
>> - Fetch previous record
>
> Which puts us back in the previous problem - once you've released a page
> of a type that can be released, there's no guarantee what you'll find
> when you go back.

We don't have to go back anymore in pages (for the previous node), because the last node on every
bucket contains the same data as on the next page.

Regards,
Arno Brinkman
ABVisie

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Firebird open source database (based on IB-OE) with many SQL-99 features :
http://www.firebirdsql.org
http://www.firebirdsql.info
http://www.fingerbird.de/
http://www.comunidade-firebird.org/

Support list for Interbase and Firebird users :
firebird-support@yahoogroups.com

Nederlandse firebird nieuwsgroep :
news://newsgroups.firebirdsql.info