From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Teodor Macicas <teodor(dot)macicas(at)epfl(dot)ch> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Inserting additional data into pg_statistics |
Date: | 2010-06-21 14:23:06 |
Message-ID: | 12138.1277130186@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Teodor Macicas <teodor(dot)macicas(at)epfl(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2010-06-21 14:34:23 | Re: Inserting additional data into pg_statistics |
Previous Message | Geoffrey | 2010-06-21 13:52:38 | Re: pgpool |