Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id B1C921337D50 for ; Thu, 16 Sep 2010 16:02:14 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 26047-01 for ; Thu, 16 Sep 2010 19:02:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sd-17937.dedibox.fr (sd-17937.dedibox.fr [88.191.100.74]) by mail.postgresql.org (Postfix) with ESMTP id 0AF751337D48 for ; Thu, 16 Sep 2010 16:02:06 -0300 (ADT) Received: from [192.168.10.2] (ASte-Genev-Bois-153-1-58-52.w81-249.abo.wanadoo.fr [81.249.208.52]) by sd-17937.dedibox.fr (Postfix) with ESMTPA id 7EAE73B8F5; Thu, 16 Sep 2010 21:02:06 +0200 (CEST) Message-ID: <4C9269AF.8070002@lelarge.info> Date: Thu, 16 Sep 2010 21:02:07 +0200 From: Guillaume Lelarge User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Josh Berkus CC: pgsql-performance@postgresql.org Subject: Re: Where does data in pg_stat_user_tables come from? References: <4C8EAE5E.70201@agliodbs.com> <1284421288.28610.501.camel@jd-desktop.unknown.charter.com> <4C8EB813.6070204@agliodbs.com> <1284423128.28610.592.camel@jd-desktop.unknown.charter.com> <4C8EC79F.9080404@agliodbs.com> <1284436337-sup-9871@alvh.no-ip.org> <4C92645A.1040208@agliodbs.com> In-Reply-To: <4C92645A.1040208@agliodbs.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201009/108 X-Sequence-Number: 40311 Le 16/09/2010 20:39, Josh Berkus a écrit : > >> It's been pure nonsense in this thread. Please show an example of >> what's not working. > > 1) Init a postgresql 8.3 with autovacuum disabled. > > 2) Load a backup of a database into that PostgreSQL. > > 3) Check pg_stat_user_tables. n_live_tup for all tables will be 0. > > 4) VACUUM ANALYZE the whole database. > > 5) n_live_tup will *still* be 0. Whereas reltuples in pg_class will be > reasonable accurate. > Did all your steps (except the fourth one). Works great (meaning n_live_tup is updated as it should be). I have to agree with Alvarro, this is complete nonsense. VACUUM ANALYZE doesn't change the pg_stat_*_tables columns value, the stats collector does. If your n_live_tup didn't get updated, I'm quite sure you have track_counts to off in your postgresql.conf file. >> Um ... it updates the last_autovacuum and last_autoanalyze columns, >> but the others are not its responsibility. > > Right. I'm contending that ANALYZE *should* update those columns. The postgres process executing ANALYZE surely sent this information to the stats collector (once again, if track_counts is on). Tried it tonight, works great too. > Current behavior is unintuitive and makes the stats in > pg_stat_user_tables almost useless, since you can never get even > approximately a coherent snapshot of data for all tables. > Get a look at your track_count setting. -- Guillaume http://www.postgresql.fr http://dalibo.com