On Monday 21 June 2010 7:23:06 am Tom Lane wrote:
> Teodor Macicas <teodor.macicas@epfl.ch> writes:
> > Modifying the pg_statistics is not a good idea for most
> > practical purposes.
>
> That's what I've been telling you.
>
> > We want to extend the system by doing the physical design
> > outside the production database, and hence need to replicate the
> > pg_statistics of the production database in another standing database.
>
> Well, leaving aside the question of whether that's actually anywhere
> near useful enough to justify the work, I'd *still* not support putting
> the information into the second database's pg_statistic. pg_statistic
> should contain the truth for that database's own tables. Seems like
> what you need here is a second table along the lines of
> pg_hypothetical_statistic, and then your planner hacks can include the
> knowledge to look there instead of pg_statistic when doing hypothetical
> planning.
>
> Not that that's going to solve your immediate problem: there just isn't
> any way at the SQL level to insert data into pg_statistic's anyarray
> columns. You're going to need some specialized C function that inserts
> the data, hopefully only after validating that the actual array type
> matches the column that the stats are alleged to be for.
>
> regards, tom lane
Another idea that just came to mind is to use something like
dblink
http://www.postgresql.org/docs/current/static/dblink.html
or
dbi-link
http://pgfoundry.org/projects/dbi-link
to see the information from the production db in the second db.
--
Adrian Klaver
adrian.klaver@gmail.com
