mean other than having to do an at best order n log n operation to create
the index instead of reading the index in order so the order of the operation is
merely n, and the overhead of absorbing dynamic changes to the table and
resultant changes into the index being built?
the "WHY?" question, I'm not sure, but my guess would be that they believed the
process flow of managing the changes while the new indexes was being built were
more reliable that way.
May 1991 the level of difficulty of getting the code provably correct to read
the existing index to create the new index without locks was referred to
by a guy who thought he might have to write it as "Jesus code," meaning no
disrespect, but the notion that it would require a divine being to get it
alternate psuedo code to read the index to build the new index while locking
only handfulls of blocks worth of rows at a time must not have made the cut, or
was lost in the shuffle.
Probably the advantage of the full table scan is getting a handle on
which rows need fixup in the new index image from the read consistent read to
fix it up to the current committed image before you swap it in
just guessing here.
email@example.com [mailto:firstname.lastname@example.org]On Behalf
Of Roger Xu
Sent: Wednesday, January 25, 2006 3:05
To: email@example.com; Bobak, Mark; ORACLE-L
Subject: online index
other differences besides: 1) does not lock the table; 2) does a full table
scan instead of full index scan; ?
Had read the article, but I am interested as to why Oracle is
doing a full table scan instead of full index scan for online index