Teodor Macicas <teodor.macicas@xxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
