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

Re: pg_upgrade and statistics

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>,Daniel Farina <daniel(at)heroku(dot)com>, Greg Stark <stark(at)mit(dot)edu>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade and statistics
Date: 2012-03-16 22:55:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Mar 15, 2012 at 11:46:04AM -0400, Bruce Momjian wrote:
> On Thu, Mar 15, 2012 at 11:15:42AM -0400, Andrew Dunstan wrote:
> > You're not the only person who could do that. I don't think this is
> > all down to you. It should just be understood that if the stats
> > format is changed, adjusting pg_upgrade needs to be part of the
> > change. When we modified how enums worked, we adjusted pg_upgrade at
> > the same time. That sort of thing seems totally reasonable to me.
> > 
> > I haven't looked at it, but I'm wondering how hard it is going to be
> > in practice?
> Well, the reason I am not recommending migration is because the work
> will _not_ fall on me, but rather on the larger community of developers,
> who might or might not care about pg_upgrade.  (I am concerned about
> pg_upgrade retarding development progress.)
> We are already telling developers not to change the binary storage
> format without considering pg_upgrade --- do we want to do the same for
> optimizer statistics?  Does the optimizer statistics format change more
> frequently than the storage format?  I think the answer is yes.  Does it
> change too frequently to require migration work?  I don't know the
> answer to that, partly because I would not be the one doing the work.
> Also, considering we are on the last 9.2 commit-fest, I doubt we can get
> something working for statistics migration for 9.2, I think the
> incremental statistics build approach is our only way to improve this
> for 9.2, and frankly, 9.1 users can also use the script once I post it.
> FYI, I have not received a huge number of complaints about the old
> analyze recommendation --- a few, but not a flood.  The incremental
> build approach might be good enough.
> My wild guess is that even if we migrated all statistics, the migrated
> statistics will still not have any improvements we have made in
> statistics gathering, meaning there will still be some kind of analyze
> process necessary, hopefully just on the affected tables --- that would
> be shorter, but perhaps not shorter enough to warrant the work in
> migrating the statistics.
> I am attaching the updated script and script output.
> Please, don't think I am ungrateful for the offers of help in migrating
> statistics.  I just remember how complex the discussion was when we
> modified the enum improvements to allow pg_upgrade, and how complex the
> checksum discussion was related to pg_upgrade.

Applied to git head for PG 9.2.

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + It's impossible for everything to be true. +

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2012-03-16 23:06:28
Subject: pg_upgrade and pg_config dependency
Previous:From: Noah MischDate: 2012-03-16 22:42:33
Subject: Re: pg_terminate_backend for same-role

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