Re: pg_upgrade and statistics - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade and statistics
Date
Msg-id 20120314213622.GA26534@momjian.us
Whole thread Raw
In response to Re: pg_upgrade and statistics  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: pg_upgrade and statistics  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Wed, Mar 14, 2012 at 10:40:41PM +0200, Peter Eisentraut wrote:
> On tis, 2012-03-13 at 20:34 -0400, Bruce Momjian wrote:
> > I frankly am worried that if we copy over statistics even in ASCII
> > that don't match what the server expects, it might lead to a crash,
> > which has me back to wanting to speed up vacuumdb.
> 
> Why can't we maintain a conversion routine for statistics from older
> versions?  It's not like the statistics layout changes every week.
> pg_dump could print out something like
> 
> SELECT pg_restore_statistics(catversion, tablename, ... some data ...);
> ...
> 
> and that function would have the knowledge to convert the data and
> insert it back into pg_statistic and pg_class.
> 
> That can't be that hard considering all the other work we put into
> backward compatibility and upgrade capability.

Well, I have not had to make major adjustments to pg_upgrade since 9.0,
meaning the code is almost complete unchanged and does not require
additional testing for each major release.  If we go down the road of
dumping stats, we will need to adjust for stats changes and test this to
make sure we have made the proper adjustment for every major release.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Command Triggers, patch v11
Next
From: Tom Lane
Date:
Subject: Re: CREATE FOREGIN TABLE LACUNA