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-15 15:46:04
Message-ID: 20120315154604.GE26534@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Attachment Content-Type Size
analyze_new_cluster.sh application/x-sh 1.4 KB
analyze.out text/plain 1.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-03-15 15:48:42 Re: pg_upgrade and statistics
Previous Message Kevin Grittner 2012-03-15 15:20:02 Re: pg_upgrade and statistics