Hi Stephen,
> But I will say that Rushmore is not in SQL Server.
True. Rushmore is in Access (fortunately! <g>) and in most client side data
handling code, but not in SQL Server. It wouldn't make sense.
Rushmore works by creating bitmaps in memory and then checking those records
that have their corresponding bit set. In other words, Rushmore requires a
lot of memory and cannot be parallized. You have to generate all Rushmore
bitmaps before you can start checking records.
SQL Servers, OTOH, gain the speed from mainly three factors: They keep as
much of the database in memory, they try to minimze the result set on the
server and they pipe operations to perform them in parallel. An optimial
query from the server side scans through indexes and sends the results back
to the client while the server is still looping through the table. Not even
the result set is ever held completely in memory. Rushmore would not only
waste precious memory, it would also delay the point when the server starts
delivering records to the client.
Rushmore works great if you have large amounts of memory available and I/O
is a very expensive operation. That's the case on a client accessing a
database across the network. It's not the case on the server accessing the
database in memory.
--
Christof
©2007 Christof Wollenhaupt |
