Can we just get the backend that dirties the page to the posix_fadvice DONTNEED?
Or have another helper that sweeps the shared buffers and does this post-first-dirty? a. On Wed, Jan 15, 2014 at 1:34 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Jan 15, 2014 at 1:53 AM, KONDO Mitsumasa > <kondo.mitsum...@lab.ntt.co.jp> wrote: > > I create patch that can drop duplicate buffers in OS using usage_count > > alogorithm. I have developed this patch since last summer. This feature > seems to > > be discussed in hot topic, so I submit it more faster than my schedule. > > > > When usage_count is high in shared_buffers, they are hard to drop from > > shared_buffers. However, these buffers wasn't required in file cache. > Because > > they aren't accessed by postgres(postgres access to shared_buffers). > > So I create algorithm that dropping file cache which is high usage_count > in > > shared_buffers and is clean state in OS. If file cache are clean state > in OS, and > > executing posix_fadvice DONTNEED, it can only free in file cache without > writing > > physical disk. This algorithm will solve double-buffered situation > problem and > > can use memory more efficiently. > > > > I am testing DBT-2 benchmark now... > > The thing about this is that our usage counts for shared_buffers don't > really work right now; it's common for everything, or nearly > everything, to have a usage count of 5. So I'm reluctant to rely on > that for much of anything. > > -- > 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 > > -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
