---
Hi Tom,
Modifying the pg_statistics is not a good idea for most practical purposes. The modification, however, becomes a
necessityto implement automatic physical design techniques. We are developing an automatic physical designer for
Postgres.The designer will add features that most commercial systems provide right now, such as automatically selecting
indexesfor queries. My colleagues recently demonstrated a prototype version of the system at SIGMOD, and the demo
descriptioncan be found at http://www.cs.cmu.edu/~ddash/parinda-sigmod.pdf
We want to extend the system by doing the physical design outside the production database, and hence need to
replicatethe pg_statistics of the production database in another standing database. This is the reason, we would like
tomove the pg_statistics across the database, and both direct sql/pg_dump-restore mechanisms fail us.
-Dash Debabrata
Tom Lane wrote:
> Teodor Macicas <teodor.macicas@epfl.ch> writes:
>
>> Why I can't ? And for my purpose is not a bad idea. I mean, I have to do
>> this and somehow I should find a solution.
>>
>
>
>> In order to use ANALYZE I need the same data on 2nd machine, but the
>> data is quite large and the only information I need are the statistics
>> from pg_statistic.
>>
>
> Er, if you haven't got the data on the second machine, then you *don't*
> need or want that stuff in its pg_statistic. It won't do you any good
> to have incorrect information in there.
>
> regards, tom lane
>