Re: Allow vacuumdb to only analyze

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "decibel" <decibel(at)decibel(dot)org>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow vacuumdb to only analyze
Date: 2009-05-27 15:29:35
Message-ID: 4A1D160F.EE98.0025.1@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> I noticed in Bruce's talk that there are a number of post-migration
> steps which are currently partially manual. Ideally we'd like to
> automate them all, preferably in some sort of well-thought-out
order.
> I actually suspect this is something like: analyze each database,
> reindex those indices invalidated by the upgrade, analyze each
> database again.

We have found it useful to VACUUM FREEZE ANALYZE a converted database.
The first access to any page will cause writing of hint bits, and
we'd rather deal with that before we let the users in, to avoid having
sluggish performance for them while that happens. The FREEZE part is
to avoid a freeze of all subsequently untouched data in all tables at
some unpredictable time -- potentially in the middle of a busy
workday. The usual argument against aggressive freezing (that
forensic information useful in recovery of a corrupted database)
doesn't carry much weight right after a conversion.

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Markus Wanner 2009-05-27 15:44:41 Re: PostgreSQL Developer meeting minutes up
Previous Message Fujii Masao 2009-05-27 15:00:50 Re: Synchronous replication: Promotion of Standby to Primary