On Sun, Jun 21, 2015 at 12:52 PM, Andres Freund <and...@anarazel.de> wrote: > On 2015-06-21 12:40:50 -0400, Tom Lane wrote: >> Andres Freund <and...@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.
But it hasn't been made to work on Windows, and is probably pretty lightly tested elsewhere. Besides, memory mapping a disk file has no real advantages over a DSM that doesn't get written to disk. I/O is a serious problem where the stats file is concerned, and more to the point, the process that reads the file goes around and puts it back into memory anyway. > 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). 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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers