Message-ID: <52A25E5C.9090405@fuzzy.cz>
Date: Sat, 07 Dec 2013 00:31:40 +0100
From: Tomas Vondra <tv@fuzzy.cz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Reseting statistics counters
References: 
 <CANL7jAR===hU5dMy6SW4kKLVkx-Uf_rKJxFZFOf-xMTtd=nnWg@mail.gmail.com>
 <CADKbJJW3W8n6MWh3qzxutAKo5Dx176X5iTzDo6xxM8n3y4Ro2g@mail.gmail.com>
In-Reply-To: 
 <CADKbJJW3W8n6MWh3qzxutAKo5Dx176X5iTzDo6xxM8n3y4Ro2g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 16.11.2013 20:49, Strahinja Kustudić wrote:
> Sorry for the late reply, but as far as I know when you run 
> pg_stat_reset() you should always run analyze manually of the
> database to populate the statistics.

Why?

There are two kinds of stats in the database - stats used by the planner
(common column values, histograms, ...) and runtime stats. pg_stat_reset
only deals with the latter, it won't discard histograms or anything like
that.

And runnning analyze won't magically populate the runtime stats - for
example how could it populate number of sequential/index scans or the
timestamp of the last autovacuum?

The only thing that may be influenced by this is autovacuum, because
this will remove timestamp of the last run on the tables, number of
deleted/dead tuples etc. So it will be invoked on all tables, collecting
this info.

regards
Tomas


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance