Is it realistic to assume that the data in tableA and tableB will never be in cache? What percentage of queries run on the system will be run when all of the data has to be pulled from disk?
There are two trains of thought on testing queries and comparing them:
- run them both with a cold cache (where you clear cache / buffers etc. before every single query)
- run them both with a warm cache (where you first prime the cache by running the queries multiple times before bothering to start comparing metrics)
Since ideally in real-world scenarios you will be dealing with 2. most of the time, it seems relatively futile to spend too much effort on 1. Unless you are in a case where the production environment is really low on memory, in which case I would rather spend money on more memory than the labor costs of trying to compare and tune queries that are always going to be dependent on physical I/O. I would think that realistic testing of 2. is more useful than 1., again in most cases.
If you really want to do this, I suppose you could forcefully fill up the buffer with data from other tables, supplanting the data from these two. Though I would be really concerned about tinkering this way too much with a system where you don't have sysadmin privileges (it's probably for exactly this reason, or at least one of the reasons).
The other suggestion would be: take a backup of the database, and restore it to a system where you are sysadmin. This may be dealing with different I/O subsystems, but aside from the differences in pure I/O performance, the relative differences between the queries should still be useful to compare when you can free the cache and the buffers freely.