Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade and statistics

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Daniel Farina <daniel(at)heroku(dot)com>, Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: pg_upgrade and statistics
Date: 2012-03-13 22:30:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Mar 13, 2012 at 5:42 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> What is the target=10 duration?  I think 10 is as low as we can
> acceptably recommend.  Should we recommend they run vacuumdb twice, once
> with default_statistics_target = 4, and another with the default?

I'm not sure why we're so glibly rejecting Dan's original proposal.
Sure, adjusting pg_upgrade when we whack around pg_statistic is work,
but who ever said that a workable in-place upgrade facility would be
maintenance-free?  We're operating under a number of restrictions
imposed by the need to be pg_upgrade-compatible, and this doesn't
strike me as a particularly severe one by comparison -- we can always
arrange to NOT migrate statistics between incompatible versions; that
doesn't mean that we shouldn't migrate them when they ARE compatible.
Also, unlike the alternatives thus far proposed, Dan's idea actually
fixes the problem.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2012-03-13 22:33:29
Subject: Re: pg_upgrade and statistics
Previous:From: Robert HaasDate: 2012-03-13 22:23:33
Subject: Re: wal_buffers, redux

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group