Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wxvpx-0002cX-Vh for pgsql-performance@arkaria.postgresql.org; Fri, 20 Jun 2014 10:14:26 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Wxvpx-0003qO-G4 for pgsql-performance@arkaria.postgresql.org; Fri, 20 Jun 2014 10:14:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Wxvpw-0003qF-D8 for pgsql-performance@postgresql.org; Fri, 20 Jun 2014 10:14:24 +0000 Received: from smtp-out1.gransy.com ([77.78.126.51]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wxvpt-0004f5-5i for pgsql-performance@postgresql.org; Fri, 20 Jun 2014 10:14:23 +0000 Received: from smtp-out.gransy.com (localhost [127.0.0.1]) by smtp-out1.gransy.com (Postfix) with ESMTP id 40EB4360038 for ; Fri, 20 Jun 2014 12:14:18 +0200 (CEST) Received: from smtp.gransy.com (smtp.simplia.cz [77.78.126.20]) by smtp-out1.gransy.com (Postfix) with ESMTP id EE459360005; Fri, 20 Jun 2014 12:14:17 +0200 (CEST) Received: from sq.gransy.com (elizabeth.gransy.com [89.187.132.199]) (Authenticated sender: tv@fuzzy.cz) by smtp.gransy.com (Postfix) with ESMTPA id CE38919A0684; Fri, 20 Jun 2014 12:14:14 +0200 (CEST) Received: from 212.47.19.46 (SquirrelMail authenticated user tv@fuzzy.cz) by sq.gransy.com with HTTP; Fri, 20 Jun 2014 12:14:16 +0200 Message-ID: <14a9b449f48a4990ac2c605b653323cc.squirrel@sq.gransy.com> In-Reply-To: References: Date: Fri, 20 Jun 2014 12:14:16 +0200 Subject: Re: huge pgstat.stat file on PostgreSQL 8.3.24 From: "Tomas Vondra" To: "Pavel Stehule" Cc: "Huang, Suya" , "pgsql-performance@postgresql.org" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 20 Červen 2014, 5:33, Pavel Stehule wrote: > 2014-06-20 1:44 GMT+02:00 Huang, Suya : >> >> Thanks Pavel, to be more clear, what does " pg_stat_reset "really reset? >> In the document it says " Reset all statistics counters for the current >> database to zero(requires superuser privileges) ". I thought it would >> reset all statistics of all tables/indexes, thus why I am thinking of >> re-run analyze database to gather statistics. Because if table/indexes >> don't have statistics, the query plan would be affected which is not a >> good >> thing to a production box... I'm not so sure if I understand "run >> statistics" you mentioned here. >> > > you have true - anyway you can clean a content of this directory - but if > your database has lot of database objects, your stat file will have a > original size very early > > Pavel > No, he's not right. Suya, as I wrote in my previous message, there are two kinds of statistics in PostgreSQL a) data distribution statistics - histograms, MCV lists, number of distinct values, ... - stored in regular tables - used for planning - collected by ANALYZE - not influenced by pg_stat_reset() at all b) runtime statistics - number of scans for table/index, rows fetched from table/index, ... - tracks activity within the database - stored in pgstat.stat file (or per-db files in the recent releases) - used for monitoring, not for planning - removed by pg_stat_reset() So running pg_stat_reset will not hurt planning at all. 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