On Monday 21 June 2010 7:23:06 am Tom Lane wrote: > Teodor Macicas <teodor.maci...@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.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
