Comments on: Shared Pool

By: Graham

Graham — Fri, 14 Dec 2007 11:26:16 +0000

I think I understand what Duncan is saying here. When developing SQL I want to know what my users will experience the first time they run it not the “artificial” run times I get as a developer because I have execeuted this SQL repeatedly and ended up with all my data cached.

>> Indeed, timings based on non-cached results are nigh-on meaningless.
Nort necessarily. In development I might run some SQL statment hundreds of times a day (because I’m developing it) but in production the same SQL might only get run once or a few times a day. I have 16Gb of RAM in my production DB server and old data will get thrown out of cache very rapidly.

Knowing how to flush cached data and cached SQL statements in development is very useful in order to better predict run times in production.

By: dizwell

dizwell — Thu, 13 Dec 2007 22:15:56 +0000

Cacheing is what the database does. Cacheing will happen in production environments. People pay good money for the software and the RAM to let cacheing happen properly and effectively.

So to declare that you should run a piece of SQL in a non-cached way because that’s its “natural way” of being run is, to me, utterly bizarre. Not cacheing something is about as UNnatural a way of doing things as you can get.

The statement, “We need to flush any mentions of our SQL from the shared pool” is, in other words, seriously loopy!

On the contrary, you definitely WANT to time your SQL in a cached environment that is similar in size and stress to what would exist in a production setting. Indeed, timings based on non-cached results are nigh-on meaningless.