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

From Tom Lane
Subject Re: pg_migrator to /contrib in a later 9.0 beta
Date
Msg-id 16043.1273155545@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_migrator to /contrib in a later 9.0 beta  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_migrator to /contrib in a later 9.0 beta
Re: pg_migrator to /contrib in a later 9.0 beta
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Mike Fowler
Date:
Subject: Adding xpath_exists function
Next
From: Simon Riggs
Date:
Subject: Re: max_standby_delay considered harmful