Willy-Bas Loos wrote:
> But that's only the OS cache. There's also the shared_buffers, which
> are a postgres specific thing.
> I've found DISCARD in the manual
> <http://www.postgresql.org/docs/8.3/interactive/sql-discard.html>, but
> that only influences a single session, not the shared buffers.
> I reckon restarting the cluster should help, would it wipe out the
> cache? (pg_ctlcluster 8.3 main restart)
> Or is there a more graceful way?
Stop the cluster; flush the OS cache; start the cluster again. Now you
have a clean cache to retest again. No easier way that's reliable. If
you try to clear out the database by doing things like scanning large
tables not involved in the query, you'll discover features in PostgreSQL
will specifically defeat that from using more than a small portion of
the cache. Better to just do a full shutdown.
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
In response to
pgsql-performance by date
|Next:||From: Greg Smith||Date: 2010-08-27 17:30:50|
|Subject: Re: Slow Query|
|Previous:||From: Greg Smith||Date: 2010-08-27 17:25:08|
|Subject: Re: Performance on new 64bit server compared to my 32bit