Re: Inserting additional data into pg_statistics - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Inserting additional data into pg_statistics
Date
Msg-id 201006210734.23840.adrian.klaver@gmail.com
Whole thread Raw
In response to Re: Inserting additional data into pg_statistics  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
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

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Inserting additional data into pg_statistics
Next
From: Guillaume Lelarge
Date:
Subject: Re: pgpool