Re: pg_stat_*_columns? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pg_stat_*_columns?
Date
Msg-id 20150621165205.GE9243@alap3.anarazel.de
Whole thread Raw
In response to Re: pg_stat_*_columns?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_stat_*_columns?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2015-06-21 12:40:50 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.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).



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Backpatch src/test/modules to 9.3?
Next
From: Andres Freund
Date:
Subject: Rework the way multixact truncations work