On Sun, Jun 21, 2015 at 12:52 PM, Andres Freund <andres@anarazel.de> wrote:
> 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.
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
