Hi Mike (and good to see you're back, by the way),

First let me say, for other readers of this thread as well as to you, that I have never "worried" much as to exactly HOW Rushmore operates, as long as I understand *when* it operates to give me the nice fast access we all like to enjoy.
I have also found that the speculative stuff about Rushmore's operation is exactly that - SPECULATIVE. Any time that I have come across a theory on it I found it left me wondering about 'details' that didn't seem to 'fit' the theory being proposed.
more below, following yours...

>Hey Jim!
>
>
>>>The speculation about the bit-mapping doesn't seem to make allowances for B-Tree functionality. Surely that has to play some important role in all of this.
><<
>
>The b-tree would only apply during a seek operation.
>
>>>
>Similarly, speculation about the bit-mapping implies (to me, as I have read this thread) that the whole index would necessarily be read into RAM. I have to wonder about this too.
>
>Finally, and this may be what Dragan was saying, even if the whole index *is* read in, the order should be immaterial for bit-map *building* purposes, since the record number is supplied with each index entry (thus providing the offset for the bit in question anyway).
><<
>
>Actually the bitmap is built based on the index tags. That precludes keeping the entire index tag in RAM which could become very difficult. Assuming a 4 byte record number and a single bit for the condition, you'd need 5 bits per record.
>
>A single bit per record would require 1/5th the storage in RAM. However, the bitmap could not be built in anything other than record # order if its only 1 bit per record.

I should have been a tad more precise in my comment...my "since the record number is supplied with each index entry (thus providing the offset for the bit in question anyway)" was meant to imply that the bit represented the record's POSITION (ie the Recno is the 'offset' into the bitmap). So the bitmap would of course be in record number order BUT the building of the bitmap could be done from/for any particular index using the offsets to set the appropriate bit ON.
But what about the index VALUE??? What good is a bitmap of records 'belonging' to an index if the VALUE of the record in question's index is not also there? This is where I suspect that b-tree has some relevance.

But my main concern is a POSSIBLE change in Rushmore's processing which may have significant impact on existing application performance as well as how we deploy it in the future.
**IF** it has changed (and I've gotta believe that it has, given what is being reported recently compared to the long-standing 'standards' religiously practised by most) then I have some real problems and I think that we all should feel similarly.

I remember that you had, when we worked together, two primary interests in FP, those being SQL and data access performance. So I know that you were far deeper into the Rushmore theories than I ever was. I wonder if you might have some old benchmark/test results which could shed some light on this situation???

Cheers,

Jim

Cheers