Thread: Taking the cache out of the equation?

Taking the cache out of the equation?

From
Rob Sargent
Date:
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.)


Re: Taking the cache out of the equation?

From
Erik Jones
Date:
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







Re: Taking the cache out of the equation?

From
Greg Stark
Date:
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