Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fmX4T-0006Sw-2f for pgsql-admin@arkaria.postgresql.org; Mon, 06 Aug 2018 04:24:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fmX4R-0006Dz-7a for pgsql-admin@arkaria.postgresql.org; Mon, 06 Aug 2018 04:24:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fmX4R-0006Ds-06 for pgsql-admin@lists.postgresql.org; Mon, 06 Aug 2018 04:24:39 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fmX4J-00077x-O5 for pgsql-admin@postgresql.org; Mon, 06 Aug 2018 04:24:38 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w764OSiq001640; Mon, 6 Aug 2018 00:24:28 -0400 From: Tom Lane To: Keith cc: Mai Peng , "pgsql-admin@postgresql.org" Subject: Re: n_live_tup number double after migration do PG 10.4 In-reply-to: References: Comments: In-reply-to Keith message dated "Sun, 05 Aug 2018 19:51:25 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1638.1533529468.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Mon, 06 Aug 2018 00:24:28 -0400 Message-ID: <1639.1533529468@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Keith writes: > On Sun, Aug 5, 2018 at 5:29 AM, Mai Peng > wrote: >> After the migration to pg 10 by pg_upgrade and vacuumdb, I’ve seen the >> number of live tuple double and performance decreases on few queries. > The value stored in n_liv_tup is the value seen when the last analyze was > run on the table. No, you're confusing this with pg_class.reltuples. I think the OP is talking about pg_stat counters such as pg_stat_all_tables.n_live_tup. Those should update after every transaction, although there are various reasons why they might be inaccurate. The OP hasn't given us nearly enough information to speculate usefully on what he's seeing. I'd suggest reading https://wiki.postgresql.org/wiki/Guide_to_reporting_problems regards, tom lane