Обсуждение: Taking the cache out of the equation?
Caching helps a *lot* and I'm thankful for that but I would like to take it out of the picture as I massage my queries for better performance. Naturally the first invocation of the query cannot take advantage of the cache and these queries would normally only be called once for the same target data. What tricks are there to flush, ignore, circumvent the caching boost? (Especially in the production environment.)
On Jun 9, 2009, at 10:51 AM, Rob Sargent wrote: > Caching helps a *lot* and I'm thankful for that but I would like to > take it out of the picture as I massage my queries for better > performance. Naturally the first invocation of the query cannot > take advantage of the cache and these queries would normally only be > called once for the same target data. What tricks are there to > flush, ignore, circumvent the caching boost? (Especially in the > production environment.) Why on earth would you want your queries to always go to disk? Erik Jones, Database Administrator Engine Yard Support, Scalability, Reliability 866.518.9273 x 260 Location: US/Pacific IRC: mage2k
On Sat, Jun 13, 2009 at 12:12 AM, Erik Jones<ejones@engineyard.com> wrote: > > On Jun 9, 2009, at 10:51 AM, Rob Sargent wrote: > >> Caching helps a *lot* and I'm thankful for that but I would like to take >> it out of the picture as I massage my queries for better performance. >> Naturally the first invocation of the query cannot take advantage of the >> cache and these queries would normally only be called once for the same >> target data. What tricks are there to flush, ignore, circumvent the >> caching boost? (Especially in the production environment.) > > Why on earth would you want your queries to always go to disk? I think he answered that in the original message -- to better represent the real workload. Unfortunately there isn't really a good answer. On Linux you can echo 1 > /proc/sys/vm/drop_caches but that doesn't affect the postgres shared buffers and worse, it does affect other buffers that probably would still be cached. The best answer is usually to build a test configuration large enough that it has similar cache effects as your production environment. Then test random values and repeat the test many times to avoid any random fluctuations. -- greg http://mit.edu/~gsstark/resume.pdf