| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Jesper Krogh <jesper(at)krogh(dot)cc>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_migrator to /contrib in a later 9.0 beta |
| Date: | 2010-05-06 14:19:05 |
| Message-ID: | 16043.1273155545@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2010-05-06 14:24:54 | Re: max_standby_delay considered harmful |
| Previous Message | Mike Fowler | 2010-05-06 14:10:15 | Adding xpath_exists function |