Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id D7FF31337E2D for ; Thu, 16 Sep 2010 16:15:01 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 05345-01 for ; Thu, 16 Sep 2010 19:14:54 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 2D5701337E32 for ; Thu, 16 Sep 2010 16:14:54 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o8GJEYDT005577; Thu, 16 Sep 2010 15:14:34 -0400 (EDT) To: Josh Berkus cc: pgsql-performance@postgresql.org Subject: Re: Where does data in pg_stat_user_tables come from? In-reply-to: <4C92645A.1040208@agliodbs.com> 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> Comments: In-reply-to Josh Berkus message dated "Thu, 16 Sep 2010 11:39:22 -0700" Date: Thu, 16 Sep 2010 15:14:34 -0400 Message-ID: <5576.1284664474@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201009/109 X-Sequence-Number: 40312 Josh Berkus writes: >> 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. Really? It works for me. You sure this installation hasn't got stats disabled? Check the beginning of the postmaster log to see if there are any bleats about failing to start the stats collector. > 4) VACUUM ANALYZE the whole database. > 5) n_live_tup will *still* be 0. Whereas reltuples in pg_class will be > reasonable accurate. It's possible you are seeing the effects of the fact that pre-9.0, vacuum and analyze wouldn't create a stats entry for a table that didn't have one already. However, it's entirely not clear why you wouldn't have one already. Also, if you didn't, you wouldn't see any row at all in the pg_stat_user_tables, not a row with n_live_tup = 0. In any case, it's clear that your installation is not operating as intended, and as 8.3 does work for me here. Better look for something interfering with stats collection. regards, tom lane