| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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-21 16:52:05 |
| Message-ID: | 20150621165205.GE9243@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015-06-21 12:40:50 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > We could also just mmap() the stats file into memory in various
> > processes. With a bit care it should be quite possible to only mmap a
> > subsets of the file at once, taking care of the address space issues.
>
> I think we should go into this with the mindset of re-using the DSM
> infrastructure, rather than inventing a new mechanism of uncertain
> portability.
Maybe. I'm rather doubtful that it's a good idea to make a choice
that'll basically force all the stats to always be in memory though.8
mmap()ing a file is one of the mechanisms for dsm, so it'd not be
totally unproven.
In totally different crazy way we could just use the existing buffer
manager we have and simply put the stats file in
shared_buffers. Inventing a per-database relfilenode that doesn't
conflict doesn't seem impossible. With some care it shouldn't be hard to
make that stats file readable from all sessions, even if they're not
connected to the database (e.g. autovacuum launcher).
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-06-21 19:24:09 | Rework the way multixact truncations work |
| Previous Message | Tom Lane | 2015-06-21 16:48:10 | Re: Backpatch src/test/modules to 9.3? |