Re: pg_migrator to /contrib in a later 9.0 beta - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_migrator to /contrib in a later 9.0 beta
Date
Msg-id 201005061514.o46FEUB20492@momjian.us
Whole thread Raw
In response to Re: pg_migrator to /contrib in a later 9.0 beta  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Jesper Krogh wrote:
> >> I should have written:
> >> Why isn't statistics copied over or why doesnt pg_migrator run analyze by
> >> itself?
> 
> > Yeah, the statistics are part of the system tables, and system tables
> > are fully handled by pg_dumpall --schema-only (except for statistics). 
> > There might be changes in the system table statistics format that would
> > break if pg_migrator tried to migrate the statistics.
> 
> Right, it's not really practical for pg_migrator to just copy over the
> statistics without any intelligence.  We might at some time choose to
> teach it which stats could be copied safely, but that hardly seems like
> something to do in version 1.0 --- and anyway it could not be a 100%
> solution.
> 
> > And if pg_migrator ran analyze itself, it would greatly increase its
> > great migration times!
> 
> Exactly.  It's not a win for pg_migrator to not give you back control of
> the database until everything has been ANALYZEd.  That's a task that can
> likely be done in background.

I have to keep those sub-minute migration times for bragging rights. :-)

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: max_standby_delay considered harmful
Next
From: Bruce Momjian
Date:
Subject: Re: pg_migrator to /contrib in a later 9.0 beta