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: 20120316225504.GE28340@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

In response to

Browse pgsql-hackers by date

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