From: Tom Lane <tgl@sss.pgh.pa.us>
To: Don Seiler <don@seiler.us>
cc: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: Stats Disappear After Minor Upgrade?
In-reply-to: 
 <CAHJZqBAQNLK1xa3pRqr9f7qUCaHqKJ9r_4Ymu1J_jSTQQw26iA@mail.gmail.com>
References: 
 <CAHJZqBAQNLK1xa3pRqr9f7qUCaHqKJ9r_4Ymu1J_jSTQQw26iA@mail.gmail.com>
Comments: In-reply-to Don Seiler <don@seiler.us>
	message dated "Tue, 15 Aug 2017 16:49:29 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7373.1502837455.1@sss.pgh.pa.us>
Date: Tue, 15 Aug 2017 18:50:55 -0400
Message-ID: <7374.1502837455@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Don Seiler <don@seiler.us> writes:
> I'm testing an upgrade of a database from 9.2.10 to 9.2.22. The upgrade
> seemingly had no problems and I started the DB. However when I went to look
> at some vacuum-related status, every table had n_dead_tup and n_live_tup =
> 0.

How did you shut down the existing installation?  This'd be expected if
you used "--mode immediate".  Otherwise, I'd have thought those stats
would still be there.

> For what it's worth, this DB was a clone of a prod standby. I didn't think
> to check the stats after opening the new clone (renamed the recovery.conf),
> so I can't say for sure what it looked like prior to upgrade. I've kicked
> off a DB-wide analyze but obviously that takes a long time and more or less
> would mean prod app downtime as the optimizer would make all sorts of goofy
> decisions until the stats are in place.

The optimizer's decisions are generally not based on the stats collector's
info, but on the contents of pg_statistic.  This observation doesn't prove
anything about whether that was intact ... but I'd be really surprised
if it wasn't.

			regards, tom lane


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