mmm, now that's the difference between guessing and knowing.

Just for clarification: > To prevent internal deadlocks, only threads

> traversing the index to the right can do lock handoffs.

Does this mean that FB, when traversing an index, locks the remainder of the
index it has to traverse?
What does the lock prohibit? Updates to the index or just page splits?

"Lock Handoffs" to me is when a large rubgy player, with the ball, uses an
outstretched arm (palm showing), to deter another rubgy player from
grappling him to the floor.

JAC
JAC2 Consultancy
Now back to full time consultancy, having just left my IT Directorship of a
SME.

I read with interest today that "We can typically achieve 700 to 800 percent
in terms of ROI by indentifying stranded assets in the service provider
environment." in IT Week..... I think he meant their software is good at
finding broken things. How can I compete in the age where marketing people
"do IT".




""Ann W. Harrison""

> > Why cannot use FB any index on select with desc order?
> > > So, i need to create 2 indexes to all table, where i need desc order
> > > with high response time.
>
> At 12:41 PM 5/20/2002 +0100, Jason Chapman (JAC2) wrote:
> >My guess is that indexed values are compressed based on the prior index
> >value, therefore you have to traverse them in a forward direction
>
>
> Jason is right, but compression is only half the problem. Originally,
> the index pages at each level pointed only to the next node to the right
> (and of course, down for higher level nodes). That made navigating an
> index backward nearly impossible. Left pointers were added to allow
> automatic rebalancing after deletes, but navigation to the left is
> complicated and expensive. To prevent internal deadlocks, only threads
> traversing the index to the right can do lock handoffs. A thread going
> left must be prepared to restablish itself from the top of the index
> each time it attempts to move left one block in the index.
>