| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joel Jacobson <joel(at)trustly(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_stat_*_columns? |
| Date: | 2015-06-24 08:43:43 |
| Message-ID: | 20150624084343.GC23915@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015-06-23 16:32:54 -0400, Robert Haas wrote:
> On Tue, Jun 23, 2015 at 3:47 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2015-06-22 21:05:52 -0400, Robert Haas wrote:
> >> Interesting idea. We could consider the set of stats files a database
> >> unto itself and reserve a low-numbered OID for it. The obvious thing
> >> to do is use the database's OID as the relfilenode, but then how do
> >> you replace the stats file?
> >
> > The relmapper infrastructure should be able to take care of that.
>
> How? I think it assumes that the number of mapped entries is pretty small.
Well, we could just use one stats file for all of the stats - that'd not
necessarily be bad. The relmapper would just be there to be able, if we
need it, to rewrite them in the background. The other alternative is to
place the stats file in the target database instead of pg_global, in
which case we can just use the per database relmapper.
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2015-06-24 08:45:52 | Re: Hash index creation warning |
| Previous Message | Michael Paquier | 2015-06-24 07:06:19 | Re: Hash index creation warning |