Re: [PERFORM] Evaluating query performance with caching in PostgreSQL 9.1.6

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: fburgess(at)radiantblue(dot)com
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: [PERFORM] Evaluating query performance with caching in PostgreSQL 9.1.6
Date: 2013-05-31 16:57:19
Message-ID: CABRT9RBKG4XiZH2_2t=kGN-StsjPaWknUrbMp_18LTuOv3OWeg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

On Fri, May 31, 2013 at 7:32 PM, <fburgess(at)radiantblue(dot)com> wrote:
> 1.) Is there any way to clear the cache so that we can ensure that when we
> run "explain analyze" on a query and make some minor adjustments to that
> query and re-execute, the plan is not cached.

PostgreSQL doesn't cache query plans if you do a normal "SELECT" or
"EXPLAIN ANALYZE SELECT" query. Plans are cached only if you use
prepared queries:
1. Embedded queries within PL/pgSQL procedures
2. Explicit PREPARE/EXECUTE commands
3. PQprepare in the libpq library (or other client library)

If you don't use these, then you are experiencing something else and
not "plan cache".

Maybe you're referring to disk cache. The only way to clear
PostgreSQL's cache (shared buffers) is to restart it, but there is
another level of caching done by the operating system.

On Linux you can drop the OS cache using:
echo 1 > /proc/sys/vm/drop_caches

> 2.) I am noticing that when I look at pg_stat_activities: autovacuum is
> re-processing some old Partition tables way back in 2007, which are static
> and are essentially read-only partitions. the line item in pg_stat reads as
> follows: autovacuum:VACUUM public.digi_sas_y2007m07 (to prevent wraparound).
> Is there a way to have autovacuum skip these static type partition tables,

No. This is a necessary and critical operation. PostgreSQL stores row
visibility information based on 32-bit transaction IDs (xids). This
value is small enough that it can wrap around, so very old tables need
to be "frozen". Details here:
http://www.postgresql.org/docs/9.1/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND

If this is a problem for you then you may want to schedule manual
VACUUM FREEZE on old tables during low usage periods.

Regards,
Marti

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David Salisbury 2013-05-31 21:37:12 Using a CTE for an update
Previous Message fburgess 2013-05-31 16:32:54 Evaluating query performance with caching in PostgreSQL 9.1.6

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2013-05-31 18:54:15 Re: Performance bug in prepared statement binding in 9.2?
Previous Message fburgess 2013-05-31 16:32:54 Evaluating query performance with caching in PostgreSQL 9.1.6