Zri Man wrote:
I don't think can be a reverse scan at the root or non-leaf node pages
of an index.
And I think I'm right when I say that its an Algorithm that is behind a
Reverse Scan, I do know its an option when Building an index.
The question is what it gives the user.
I'm not sure how MIN and MAX can be helped by this at all.
As I said, I do not understand, given the organization of a B-Tree, how
there can be a Reverse Scan or for that matter a predicated Bias to the
Scan of an B-Tree Index.
First, I don't know exactly if DB2 works that way...
A B-Tree - as it was invented by Rudolf Bayer in the early 70s - has only
pointers/references from a parent node to its sons (and maybe even the
backwards direction). In particular, there is no pointer/reference from
one leaf node to the next/previous one.
I'd say that DB2 implements per default a "next" pointer on the leaf nodes.
Those pointers allow a sequential scan of the leaf nodes in the sort order
of the index. Also, the pointers can be maintained during a split
operation without any additional I/O.
But note that you cannot do a reverse scan on the leaf nodes because you
don't know the predecessor of any given leaf - there are no "prev"
pointers. That is what ALLOW REVERSE SCAN adds. You do have now a
doubled-linked list at the leaf level, and you can perform index scans in
ascending and descending order. Besides the few bytes overhead for the
pointer (which is negligible), you will have to maintain the linked list
all the time, and that means you have 1 additional I/O operation because
the "prev" pointer of the successor page of the page being split has to be
corrected.
I don't know right now if there are other considerations when choosing
reverse scans. Have a look at the manual.
--
Knut Stolze
Information Integration Development
IBM Germany / University of Jena