Re: Taking the cache out of the equation?

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Erik Jones <ejones(at)engineyard(dot)com>
Cc: Rob Sargent <robjsargent(at)gmail(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: Taking the cache out of the equation?
Date: 2009-06-12 22:25:19
Message-ID: 407d949e0906121525w1e0f13f0vf41bd9f63c032ebe@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Sat, Jun 13, 2009 at 12:12 AM, Erik Jones<ejones(at)engineyard(dot)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

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Seb 2009-06-13 00:22:27 Re: updateable/insertable view having left joined tables
Previous Message Erik Jones 2009-06-12 22:12:57 Re: Taking the cache out of the equation?