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 _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
